Чек-лист безопасности сайта и веб-приложения перед запуском

Список ниже подходит для первичной проверки коммерческого сайта, личного кабинета или API. Он не заменяет моделирование угроз, ревью кода и пентест. Глубина зависит от данных, ролей, платежей, интеграций и возможного ущерба. Проверки активными методами проводят только с письменного разрешения владельца и в согласованном периметре.

Начните с самых дорогих сценариев: захват административной учётной записи, доступ к чужим данным, изменение платежа, массовая выгрузка, остановка сервиса и невозможность восстановиться. Это помогает распределить время по риску, а не по длине списка.

Проверьте каждую роль отдельно. Пользователь не должен получать чужой объект простым изменением идентификатора в URL или API. Административные функции защищают отдельными разрешениями, а не только скрытой кнопкой. Сессии завершаются после смены пароля и имеют разумный срок жизни.

Все входные данные проверяются на сервере, даже если интерфейс уже ограничивает формат. Параметризованные запросы и безопасные API исключают прямую сборку команд из пользовательского ввода. Ограничение частоты защищает формы, авторизацию и дорогие операции от автоматического злоупотребления.

Собирайте только данные, которые действительно нужны. Секреты и пароли не попадают в логи, аналитические события, URL и сообщения об ошибках. Чувствительные данные шифруются при передаче, а доступ к ним фиксируется и пересматривается.

Зафиксируйте версии зависимостей, регулярно проверяйте известные уязвимости и удаляйте неиспользуемые пакеты. Секреты хранятся в переменных среды или менеджере секретов, а не в репозитории, клиентском JavaScript или образе контейнера. Ключ, случайно попавший в историю Git, нужно отозвать, а не только удалить из последнего коммита.

Производственная сборка должна быть воспроизводимой. Разворачивайте проверенный артефакт, ограничьте права процесса и не храните инструменты разработки на публичном сервере без необходимости.

Оставьте открытыми только нужные порты, отключите парольный вход администратора, обновляйте ОС и веб-сервер из доверенных репозиториев. HTTPS должен работать на всех страницах, а HTTP - перенаправлять на канонический домен. HSTS, CSP, запрет встраивания и безопасная политика источника уменьшают поверхность атаки, но требуют проверки в реальном браузере.

Резервная копия считается рабочей только после тестового восстановления. Определите допустимую потерю данных и время простоя, храните копии отдельно от основного сервера и контролируйте результат задания, а не сам факт его запуска.

Фиксируйте входы, изменения прав, административные операции и ошибки интеграций без лишних персональных данных. Настройте уведомления о всплесках ошибок, заполнении диска, недоступности сайта и проблемах сертификата. Назначьте человека, который получает сигнал и знает следующий шаг.

До инцидента запишите, как изолировать систему, восстановить сервис, сохранить доказательства и уведомить заинтересованных лиц. Короткий проверенный план полезнее большого документа, который никто не открывал.

Отдельный пентест оправдан для кабинетов с несколькими ролями, платёжных сценариев, API партнёров, чувствительных данных и значимых изменений архитектуры. Сначала фиксируют разрешение, периметр, тестовые окна и запрещённые действия. Результат - подтверждённые находки, оценка риска, шаги воспроизведения, рекомендации и ретест исправлений.

Автоматический сканер полезен как источник гипотез, но не проверяет бизнес-логику и не доказывает каждую проблему. Поэтому отчёт без ручной валидации нельзя считать полноценным пентестом.