Открытая методология · для владельца и разработчика
Кто может управлять сайтом? Можно ли получить чужие данные? Удастся ли восстановить работу после сбоя? Разберите свой сайт по шагам — от доступов до кода и резервных копий.
Бесплатно, без регистрации. Самопроверка подскажет, что выяснить у разработчика. Технические выводы требуют проверки сайта и его настроек.
Первый шаг · без технических знаний
Отметьте известное. Если нет подтверждения, выбирайте «Не знаю»: это поможет составить вопросы тому, кто обслуживает сайт.
Ответы показывают, что вам известно о сайте. Они не подтверждают наличие уязвимости или достаточность защиты.
Подробная методология
Это рабочая основа для сайта компании, CMS или небольшого веб-сервиса. В каждой области проверяем и настройки, и поведение. Объём зависит от функций: например, без личного кабинета часть сценариев доступа будет неприменима.
У результата есть дата, проверенная версия и подтверждение: настройка, фрагмент кода или воспроизводимый сценарий на тестовой копии. В отчёте отдельно отмечаем «проверено, замечаний не выявлено», «есть замечание», «не проверено» и «не применимо» с причиной.
Проверяем свой сайт или систему с разрешения владельца. Действия, которые могут изменить данные или нарушить работу, выполняем на согласованной копии с тестовыми аккаунтами. Доступы запрашиваем под конкретные проверки.
01–05 · Доступы и вход
Для проверки: список доступов, настройки учётных записей и тестовые пользователи.
Проверяем владельца аккаунтов, контакты восстановления и ответственного за продление. Потеря связи с подрядчиком не должна лишать компанию управления сайтом.
Подтверждение: компания может войти в панели и восстановить доступ; сроки продления известны.
У администраторов отдельные учётные записи, уникальные пароли и второй фактор там, где он поддерживается. Резервный способ входа не должен обходить эту защиту.
Подтверждение: список аккаунтов и проверка входа и восстановления. Пароли в отчёт не включаем.
Сверяем полномочия с задачами сотрудников. Проверяем удаление бывших пользователей, ненужных ключей и активных сеансов.
Подтверждение: перечень ролей; отозванный доступ больше не позволяет работать с системой.
Проверяем ограничение повторных попыток, безопасное хранение паролей и одноразовое восстановление. Ошибки входа не должны раскрывать лишние сведения об аккаунте.
Подтверждение: настройки, проверка кода и безопасные сценарии на тестовой учётной записи.
Проверяем время жизни сеанса, его обновление после входа и отзыв после выхода или смены доступа. Отдельно — атрибуты cookies, в которых хранится идентификатор сеанса.
Подтверждение: завершённый сеанс не даёт повторно выполнить защищённое действие.
Основа: OWASP: аутентификация, управление сеансами.
06–10 · Компоненты сайта
Для проверки: CMS, список пакетов и плагинов, конфигурация сервера, история обновлений.
Собираем версии CMS, плагинов, библиотек и серверных компонентов. Отмечаем, кто их поддерживает и какие уже перестали получать исправления.
Подтверждение: перечень фактически установленных компонентов с версиями и источниками.
Сопоставляем предупреждения с установленной версией, настройками и используемыми функциями. Упоминание плагина в базе уязвимостей само по себе не доказывает проблему сайта.
Подтверждение: ссылка на бюллетень и вывод о применимости к конкретному компоненту.
Проверяем ответственного, порядок установки исправлений и совместимость на копии. Для срочных обновлений нужен отдельный понятный порядок действий.
Подтверждение: история обновлений, проверенные функции и доступная предыдущая версия.
Проверяем происхождение расширений и необходимость каждого из них. Неиспользуемые плагины, темы и тестовые инструменты убираем с учётом зависимостей.
Подтверждение: состав рабочей установки и источник получения оставшихся компонентов.
Проверяем отладку, сообщения об ошибках, служебные панели, архивы и копии базы. Ошибка страницы не должна раскрывать секреты или внутреннее устройство системы.
Подтверждение: конфигурация и согласованные проверки доступности служебных ресурсов.
Основа: OWASP: зависимости, настройки и публикация.
11–15 · Действия посетителя
Для проверки: код, копия сайта и тестовые аккаунты с разными правами.
Проверяем доступ к чужим записям и административным действиям для каждой роли. Скрытая кнопка или непредсказуемый адрес не заменяют проверку прав.
Подтверждение: матрица ролей и сценарии, в которых сервер отклоняет запрещённые обращения.
Разбираем обработку полей, параметров и запросов к базе. Данные пользователя должны оставаться данными, а ограничения — действовать на сервере.
Подтверждение: проверка кода запросов, типов и границ ввода; безопасные тесты на копии.
Проверяем вывод данных в страницах и интерфейсах администратора. Защита зависит от того, куда попадает текст: HTML, атрибут, адрес или сценарий.
Подтверждение: корректное кодирование или очистка в нужном контексте и тестовые примеры.
Для действий с авторизацией через cookies проверяем защиту от поддельных межсайтовых запросов. Запросы на чтение не должны выполнять защищённые операции — например удалять запись или менять настройки.
Подтверждение: защита изменяющих запросов; запрос без необходимых подтверждений отклоняется.
Если загрузка есть, проверяем тип, содержимое, размер, имя и место хранения файла. Загруженный файл не должен выполняться как серверный код.
Подтверждение: обработчик и правила хранения проверены на безопасных тестовых файлах, включая отклонённые варианты.
Основа: OWASP: права доступа, запросы к базе, вывод данных, CSRF, загрузка файлов.
16–20 · Соединение и данные
Для проверки: настройки сервера, хранилищ и приложения; код и схема передачи данных.
Проверяем сертификат, перевод HTTP на HTTPS, используемые версии TLS и смешанную загрузку ресурсов. Формы и административные действия не должны уходить по открытому соединению.
Подтверждение: проверка соединения, переходов и загрузки ресурсов на значимых страницах.
Проверяем политики загрузки контента, встраивания страниц и другие защитные заголовки. Их выбирают под функции сайта: формальное наличие заголовка не доказывает защиту.
Подтверждение: фактические ответы сервера и работа страниц с выбранной политикой.
Проверяем публичные файлы, клиентский код и историю репозитория. При утечке секрет отзывают или заменяют: удаления строки из текущего файла недостаточно.
Подтверждение: проверенные места хранения и история отзыва затронутых ключей без публикации их значений.
Проверяем права приложения к базе, файлам и облачному хранилищу. Публичные материалы отделяем от внутренних; приложению выдаём только необходимые разрешения.
Подтверждение: настройки ролей и отказ в доступе к закрытым данным из неподходящей роли.
Прослеживаем данные из формы до почты, CRM, журналов и резервных копий. Проверяем необходимость хранения, сроки удаления и защиту чувствительных сведений.
Подтверждение: схема передачи и хранения; технические настройки соответствуют согласованным правилам.
Основа: OWASP: TLS, защитные заголовки, секреты, базы данных. Правовые требования разбираем в юридической подготовке сайта.
21–25 · Интеграции и выпуск
Для проверки: код интеграций, настройки сервисов, тестовая среда и процесс публикации.
Собираем виджеты, счётчики, чат и другие подключения. Проверяем их назначение, источник и доступ к данным страницы; ненужные убираем.
Подтверждение: перечень интеграций с владельцем и понятным маршрутом данных.
Проверяем права сервисных ключей, проверку входящих уведомлений и защиту от повторной обработки. Чужой запрос не должен менять заказ или статус оплаты.
Подтверждение: настройки интеграции и тесты подлинного, неподтверждённого и повторного уведомления.
Если сайт загружает данные по введённому адресу, проверяем допустимые назначения, перенаправления и ограничения. Эта функция не должна давать посетителю несанкционированный доступ к внутренним ресурсам.
Подтверждение: правила исходящих запросов и согласованные проверки на тестовой среде.
Проверяем отдельные доступы и тестовые данные. Черновая версия не должна открывать клиентскую базу, использовать рабочие ключи или отправлять настоящие уведомления.
Подтверждение: конфигурация сред, ограниченный доступ к копии и изоляция интеграций.
Проверяем, кто выпускает код, как проходят проверки и где хранится предыдущая версия. Отдельно учитываем изменения базы: простой возврат файлов может быть недостаточен.
Подтверждение: история выпусков и проверенный порядок отката для выбранного изменения.
Основа: OWASP: внешние скрипты, вебхуки, серверные запросы, выпуск изменений.
26–30 · Контроль и восстановление
Для проверки: настройки резервирования, копии, журналы, уведомления и ответственные.
Проверяем состав, периодичность и хранение резервных копий. Компрометация рабочего сервера не должна позволять уничтожить все доступные версии.
Подтверждение: перечень копируемых данных, отдельные права и защищённое или отключённое хранилище.
Разворачиваем выбранную копию в отдельной среде. Проверяем данные, вход, формы и другие ключевые функции; фиксируем время и возможную потерю свежих данных.
Подтверждение: протокол пробного восстановления с датой копии и результатами проверки.
Проверяем записи об административных действиях, отказах входа и ошибках. В журналах не должны сохраняться пароли, ключи и лишние персональные данные.
Подтверждение: тестовое событие найдено; доступ к журналу и срок хранения ограничены.
Проверяем сигналы о недоступности, сбоях копирования и подозрительных событиях. Само наличие системы мониторинга ничего не говорит о том, кто реагирует.
Подтверждение: тестовое уведомление получено нужным человеком; порядок реакции известен.
Согласуем контакты, порядок ограничения доступа, сохранения следов, восстановления и замены секретов. Если взлом уже произошёл, объём расследования определяют отдельно.
Подтверждение: короткий план с ответственными и проверка его выполнимости.
Основа: CISA: резервирование и восстановление, OWASP: журналы и наблюдение.
После проверки
Где обнаружена проблема, при каких условиях возникает, чем подтверждается и какие данные или функции затрагивает.
Приоритет по последствиям и доступности ошибки. Отдельно — вопросы, которым не хватило данных, и рекомендации по усилению защиты.
Какое изменение внесено, как повторили исходный сценарий и какие соседние функции проверили после выпуска.
Использую OWASP ASVS 5.0.0 как ориентир технических требований, OWASP WSTG 4.2 — как руководство по проверке, а тематические рекомендации указаны у каждого раздела. Источники сверены 8 октября 2026 года.
Эти 30 пунктов — отобранные области работы, а не весь стандарт ASVS и не сертификат соответствия. Состав аудита уточняем под сайт. Проверка снижает неопределённость и помогает устранить найденные слабые места, но не гарантирует отсутствие всех уязвимостей или будущих взломов.
Я Сергей Барвинский, маркетолог и руководитель проектов. Организую проверку и исправления, использую ИИ для разбора кода. Для задач, требующих профильной экспертизы по информационной безопасности, нужен соответствующий специалист. Подробнее о формате и границах работы.