Взялась проверить собственный сайт на проникновение. Думала, управлюсь за час. Потратила пять. Нашла 12 «критических» предупреждений, из которых 2 действительно требовали действий, а 10 были либо ложными срабатываниями, либо теоретическими рисками, нерелевантными в моём случае. Этот опыт научил меня трём вещам, которыми делюсь.

Сканер не равен реальной атаке

Автоматические инструменты — sqlmap, nikto, OWASP ZAP — полезны как первая линия, но их отчёты нужно фильтровать. Из 12 предупреждений, которые я получила, 7 были вариациями одной и той же ситуации: «ваш сервер отвечает определённым заголовком, что теоретически может рассказать атакующему о версии ПО». Да, может. Но атакующему нужно ещё попасть на сервер, чтобы этим воспользоваться. Если вы закрыли доступ извне, заголовок сам по себе не проблема.

Что действительно стоит чинить

Из 12 предупреждений два были серьёзными:

  • Сохранение пользовательского ввода без санитизации в одном из обработчиков формы обратной связи. Кто-то мог отправить <script> и при определённых условиях выполнить JavaScript в браузере другого пользователя. Классический stored XSS.
  • Отсутствие rate-limit на странице авторизации. Теоретически можно перебирать пароли. Практически у меня короткий таймаут сессии и блокировка после 5 неудачных попыток — этого хватает.

Остальное — академические риски. Их тоже стоит держать в голове, но чинить «здесь и сейчас» не было смысла.

Что я добавила в свой чек-лист

После этого опыта я внесла три изменения в свой рабочий процесс:

  1. Все пользовательские данные — через escape или sanitize-html библиотеку. Без исключений. Раньше я полагалась на «я же контролирую, что приходит с формы», но это самонадеянно.
  2. Заголовки безопасности (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security) — обязательная часть конфигурации сервера, а не опция «если будет время».
  3. Rate-limit на всех публичных endpoint'ах. Не только на авторизации. Особенно там, где есть отправка писем или запись в базу.

Что я поняла про себя

Главный вывод — аудит безопасности страшен не из-за того, что найдёшь много дыр, а из-за того, что сложно отличить реальную проблему от шума сканера. Справиться с этим можно только практикой: либо через повторяющиеся проверки своих проектов, либо через чтение реальных отчётов о взломах, чтобы научиться видеть паттерны. Теория из OWASP Top 10 помогает, но без опыта применения превращается в список, который сложно приоритизировать.

Если вы давно не смотрели на свой проект глазами атакующего — попробуйте. Первый запуск сканера занимает час. Разбор отчёта — ещё несколько часов. Зато потом спите спокойнее.