Руководства

Как проверить HTTP-заголовки безопасности

Заголовки снижают конкретные риски в браузере, но не доказывают безопасность всего приложения.

Короткий ответ

Начните с HTTPS, затем проверьте CSP, защиту фреймов, nosniff и Referrer-Policy. Отсутствующий заголовок — повод для проверки, а не доказательство взлома.

Защитите транспортный уровень: HTTPS и HSTS

Отдавайте все страницы по HTTPS с валидным сертификатом. Включайте заголовок Strict-Transport-Security с положительным сроком (например, max-age=31536000) только после проверки постоянной работы HTTPS. Значение max-age=0 обнуляет политику HSTS (RFC 6797) и оставляет будущие визиты незащищёнными.

Настройте строгую политику Content-Security-Policy

Передавайте CSP в HTTP-заголовках ответа, ограничивая источники скриптов, объектов и фреймов. Запретите 'unsafe-inline' и 'unsafe-eval', откажитесь от wildcard (*) в источниках и используйте криптографические nonces или хэши для защиты от XSS.

Защитите сайт от кликджекинга и подмены MIME

Настройте директиву frame-ancestors в CSP (и заголовок X-Frame-Options: DENY для совместимости), чтобы исключить встраивание страницы в сторонние iframe. Задайте X-Content-Type-Options: nosniff, чтобы браузер не пытался исполнять файлы под видом других типов.

Включите изоляцию Cross-Origin и заголовки приватности

Для полной изоляции процесса документа требуются одновременно Cross-Origin-Opener-Policy (same-origin) и Cross-Origin-Embedder-Policy (require-corp или credentialless). Установите Referrer-Policy: strict-origin-when-cross-origin для защиты параметров URL и отключите неиспользуемые API через Permissions-Policy.

Чётко обозначайте границы аудита заголовков

Анализ HTTP-заголовков — это проверка эшелонированной защиты браузера, а не пентест. Он не может обнаружить уязвимости бизнес-логики, SQL-инъекции, недостатки авторизации или бреши в зависимостях. Комплексная безопасность требует регулярного аудита кода и тестирования на проникновение.

Запустить бесплатный аудит →