PRLab → Технический аудит → HTTP-заголовки

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

Проверка HTTP-заголовков безопасности помогает оценить настройки браузерной защиты: HSTS, Content-Security-Policy, CORS, cookie и переходы HTTP → HTTPS. Введите домен или URL, чтобы получить отчёт по 20 пунктам.

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

Проверка security headers полезна после запуска сайта, обновления CMS, изменения конфигурации nginx/Apache, подключения CDN или платёжной формы. Значения анализируются вместе с назначением политики: жёсткие ограничения могут нарушить работу iframe, OAuth и сторонних ресурсов.

1. HSTS — Strict-Transport-Security

Проверяется HTTPS и директива max-age. Значение 0 отключает политику. includeSubDomains и preload требуют отдельной подготовки, а не автоматического включения.

2. Content-Security-Policy (CSP)

Анализируются основные директивы и широкие разрешения для скриптов. Report-Only отличается от блокирующей CSP. Это базовый разбор, не доказательство отсутствия XSS.

3. X-Frame-Options

Проверяются DENY и SAMEORIGIN, учитывается CSP frame-ancestors. Политика встраивания должна соответствовать использованию сайта.

4. X-Content-Type-Options

Проверяется nosniff. Вместе с корректным Content-Type этот заголовок ограничивает угадывание браузером типа ресурса.

5. Referrer-Policy

Проверяется управление передачей адреса страницы при переходе. unsafe-url требует внимания; отсутствие явной настройки не означает отсутствия браузерного значения по умолчанию.

6. Permissions-Policy

Показывается политика доступа к функциям браузера — например, камере, микрофону и геолокации. Нужные разрешения определяются приложением.

7–9. COOP, COEP и CORP

Проверяются значения Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy и Cross-Origin-Resource-Policy. Изоляция документов и доступ к ресурсам требуют проверки совместимости.

10–11. CORS: Origin и Credentials

Анализируются Access-Control-Allow-Origin и Access-Control-Allow-Credentials, в том числе несовместимость wildcard с credentials. Динамическое отражение Origin и авторизованные запросы не тестируются.

12. X-Permitted-Cross-Domain-Policies

Проверяется значение политики для старых cross-domain клиентов. Его применимость зависит от используемых технологий.

13–14. X-XSS-Protection и Expect-CT

Устаревшие заголовки выделяются отдельно. Их отсутствие не считается недостатком; старый XSS-фильтр не заменяет CSP и защиту приложения.

15. Cache-Control

Анализируется режим кеширования. Для приватных данных и статических ресурсов нужны разные настройки; no-cache и no-store не равнозначны.

16. Set-Cookie

Проверяются Secure, HttpOnly, SameSite и ограничения префиксов cookie. SameSite=None требует Secure. HttpOnly зависит от того, нужен ли доступ из JavaScript.

17–18. Server и X-Powered-By

Отмечается раскрытие технологии и версии ПО. Скрытый баннер уменьшает объём публичной информации, но не заменяет обновления и исправления.

19–20. HTTPS и downgrade-редиректы

Проверяются переход с HTTP на HTTPS и отсутствие обратного шага HTTPS → HTTP в наблюдаемых цепочках. Недоступная цепочка помечается как непроверенная.

Как читать отчёт о безопасности заголовков

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

Почему отсутствие заголовка не всегда ошибка?

CORS может быть не нужен обычной странице; COEP способен ограничить загрузку внешних ресурсов; cookie могут отсутствовать в анонимном ответе. Поэтому сервис показывает наблюдение и пояснение, а не универсальный «балл безопасности».

Методические источники: OWASP Secure Headers и справочник HTTP-заголовков MDN.