intDataBlog
← ЖурналМаршруты обучения ↗

Проверка сайта перед публикацией: базовый контур безопасности

Сайт редко ломается из-за одной большой ошибки. Чаще проблема в наборе мелких дыр: открытая админка, слабый TLS, лишние методы, забытые бэкапы и логи без алертов.

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

Публичная поверхность

  • Открыты только нужные порты: обычно 80 и 443, SSH ограничен по IP или вынесен в отдельный контур.
  • Админки, staging и технические панели закрыты авторизацией, VPN или allowlist.
  • Старые домены, тестовые поддомены и временные reverse proxy не смотрят на production.
  • В корне сайта нет архивов, дампов, .env, логов и резервных копий.
ss -lntup
find /var/www -maxdepth 3 -type f \( -name '*.sql' -o -name '*.zip' -o -name '.env' \)

TLS и заголовки

Минимум для обычного сайта: корректный сертификат, редирект HTTP на HTTPS, HSTS после проверки всех поддоменов и запрет небезопасного встраивания.

curl -I https://example.com
curl -I http://example.com
  • Strict-Transport-Security включать только когда HTTPS стабилен на всех нужных именах.
  • X-Content-Type-Options: nosniff снижает риск неверной интерпретации файлов.
  • Content-Security-Policy лучше вводить постепенно: сначала в report-only, потом в enforcement.

Наблюдаемость

Защита без наблюдения быстро превращается в надежду. Нужны access/error logs, алерт на всплеск 4xx/5xx, контроль свободного места и понятная процедура отката.