HTTP-заголовки безопасности
Проверьте, правильно ли настроены HTTP-заголовки безопасности вашего сайта.
Как работает проверка заголовков
Инструмент отправляет обычный HTTPS GET-запрос на указанный URL и читает заголовки ответа - те же заголовки, что получает каждый браузер. Тело страницы не анализируется; заголовки безопасности целиком живут в HTTP-ответе.
Затем мы ищем заголовки, управляющие защитой на стороне браузера: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options и Referrer-Policy. Каждый присутствующий заголовок добавляет баллы, а отсутствующие перечисляются с объяснением риска, который они оставляют открытым.
Поскольку проверка следует за перенаправлениями, результат отражает конечный URL. Если ваш сайт перенаправляет с HTTP на HTTPS или с корневого домена на www, показанные заголовки относятся к месту назначения.
Как читать результаты
Оценка - это быстрый ориентир, а не сертификация. Что важно на практике:
- HSTS - говорит браузерам всегда использовать HTTPS для вашего домена. Распространённая практика - max-age не менее полугода; добавляйте includeSubDomains только если каждый поддомен работает по HTTPS.
- CSP - сильнейшая защита от XSS, но и самая сложная в написании. Даже базовая политика, ограничивающая источники скриптов, заметно лучше, чем её отсутствие.
- X-Content-Type-Options: nosniff и X-Frame-Options (или директива CSP frame-ancestors) - дешёвые однострочные защиты от MIME-sniffing и clickjacking.
Типичные проблемы
Заголовок настроен, но отображается как отсутствующий. Обратный прокси или CDN перед вашим приложением может удалять или переопределять заголовки. Сравните ответ через curl -I напрямую к origin и к публичному URL, чтобы найти слой, который его убирает.
CSP присутствует, но не работает. Content-Security-Policy-Report-Only записывает нарушения, ничего не блокируя. Это полезно для тестирования, но не даёт защиты - переключитесь на принудительный заголовок, когда журнал отчётов станет чистым.
Разные маршруты возвращают разные заголовки. Заголовки, установленные в middleware приложения, могут не применяться к статическим файлам, которые веб-сервер отдаёт напрямую, или к страницам ошибок. Проверьте также URL статического ресурса и страницу 404.
Часто задаваемые вопросы
Какие заголовки безопасности должны быть у каждого сайта?
Разумный базовый набор: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy и защита от встраивания через X-Frame-Options или CSP frame-ancestors. Для API дополнительно полезен Cache-Control: no-store на чувствительных ответах.
Нужен ли ещё заголовок X-XSS-Protection?
Нет. Современные браузеры удалили XSS-аудитор, которым он управлял, а в старых браузерах заголовок мог даже создавать уязвимости. Вместо него используйте строгую Content-Security-Policy.
Защищает ли HSTS самый первый визит?
Сам по себе нет - браузер узнаёт правило только из первого HTTPS-ответа. Чтобы покрыть первый визит, добавьте домен в список предзагрузки HSTS (hstspreload.org) и используйте директиву preload вместе с includeSubDomains.
Может ли неправильный заголовок сломать сайт?
Да, два классических случая: чрезмерно строгая CSP блокирует ваши собственные скрипты или встроенные стили, а HSTS с includeSubDomains ломает любой поддомен, который всё ещё работает по обычному HTTP. Внедряйте CSP сначала в режиме report-only, а HSTS начинайте с короткого max-age.
Отслеживайте изменения заголовков непрерывно
ePulz.io уведомит вас, когда заголовок изменится (например после развёртывания, случайно удалившего CSP).
Начать с ePulz.io →Об этом инструменте
Заголовки безопасности сообщают браузеру, как защитить ваших посетителей. Эта проверка показывает, действительно ли присутствуют HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options и Referrer-Policy, и оценивает результат, чтобы вы могли выявить пробелы для clickjacking и MIME-sniffing после развёртывания.