Проверка HTTP-заголовков
Инструмент проверки HTTP-заголовков запрашивает URL и показывает заголовки ответа, которые вернул сервер: код статуса, поля кэширования и cookie, а также заголовки безопасности, которые применяет браузер. Здесь к ним добавляется оценка от 0 до 100 по семи заголовкам: HSTS, CSP, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy и Permissions-Policy. Для github.com возвращается 200 OK примерно за 60 мс, 17 заголовков и 90/100, оценка A+.
Заголовки безопасности
Все заголовки ответа
| Header | Value |
|---|---|
Что показывает эта проверка HTTP-заголовков?
Введите домен: инструмент отправляет с нашего сервера HEAD-запрос по этому адресу, а затем показывает код статуса, время обмена в миллисекундах, полный список заголовков ответа и оценку безопасности от 0 до 100, построенную на HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy и Permissions-Policy. Он сообщает то, что прислал сервер: переадресации не отслеживает и тело страницы не читает.
Популярные
О проверке HTTP-заголовков
Этот инструмент берёт URL, отправляет по нему HEAD-запрос с нашего сервера и показывает, что вернулось: код статуса вместе с его текстовым пояснением, время обмена в миллисекундах и каждый заголовок ответа, который прислал сервер. Для github.com это 200 OK примерно за 60 мс и 17 полей заголовков — от content-type и etag до полного значения content-security-policy.
Карточка «Оценка безопасности» оценивает семь заголовков по стобалльной шкале. Strict-Transport-Security и Content-Security-Policy стоят по 20 баллов, X-Content-Type-Options и X-Frame-Options — по 15, а X-XSS-Protection, Referrer-Policy и Permissions-Policy — по 10. От 90 баллов ставится A+, от 80 — A, от 70 — B, от 60 — C, от 40 — D, ниже — F. github.com получает 90/100, потому что нет Permissions-Policy; example.com не присылает ни одного из семи и получает 0.
Оценка учитывает наличие, а не качество. Значение x-xss-protection: 0 отключает этот фильтр, но всё равно приносит свои десять баллов, а заголовок content-security-policy-report-only не приносит ни одного, поэтому читайте значения под каждой строкой с пометкой Present, а не только итоговую оценку. Переадресации не отслеживаются: google.com отвечает 301 с location: https://www.google.com/, и чтобы оценить конечную страницу, этот адрес нужно вставить в поле отдельно. Запрос выполняется методом HEAD, поэтому ни HTML, ни мета-теги, ни текст страницы не анализируются; через десять секунд запрос прерывается, а с одного адреса принимается двадцать проверок в минуту.
Введённый URL передаётся на сервер этого сайта, который выполняет запрос за вас с идентификатором FreeWebTools Header Checker/1.0 и без ваших cookie и сессии, так что вы видите ответ для анонимного посетителя. Частные и зарезервированные диапазоны IP, localhost, точки доступа к метаданным облака и служебные порты вроде 22, 3306 и 6379 отклоняются.
Примеры использования
Как проверить заголовки ответа HTTP у сайта
Введите домен или полный адрес в поле поиска, например example.com; префикс https:// будет добавлен автоматически. Можно также нажать один из примеров рядом с надписью «Попробовать»: google.com, github.com, cloudflare.com или stackoverflow.com.
Нажмите Enter или кнопку «Проверить». Запрос уходит с нашего сервера методом HEAD, поэтому возвращаются только заголовки и никогда — тело страницы.
Прочитайте три сводные карточки: «Код статуса» с текстовым пояснением, «Оценка безопасности» из 100 с буквенной оценкой и «Время ответа» в миллисекундах.
Просмотрите раздел «Заголовки безопасности» и увидите, какие из HSTS, CSP, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy и Permissions-Policy отмечены как Present или Missing, а под каждым присутствующим прочитайте его значение.
Откройте раздел «Все заголовки ответа», чтобы прочитать имя и значение каждого заголовка от сервера, включая поля кэша, cookie и CDN, которые оценка не охватывает.
Нажмите «Копировать», чтобы положить весь отчёт — URL, статус, оценку с буквой и список заголовков — в буфер обмена обычным текстом.
Советы профессионалов
- Вводите только домен: поле само добавит https://, поэтому github.com проверяется как https://github.com. Напишите http:// явно, чтобы увидеть ответ по обычному HTTP, где strict-transport-security обычно отсутствует: RFC 6797 предписывает браузерам игнорировать его на незащищённом соединении.
- Оценка вознаграждает наличие, а не значение. github.com присылает x-xss-protection: 0, то есть отключает фильтр, и всё равно получает все десять баллов, поэтому читайте серую строку со значением под каждой отметкой Present, прежде чем доверять итоговой оценке.
- Политика в режиме report-only баллов не даёт. google.com присылает content-security-policy-report-only без применяемой политики и теряет все 20 баллов CSP; отметка Present появляется только для точного имени заголовка content-security-policy.
- Если карточка «Код статуса» показывает 301 или 302, скопируйте значение location из таблицы заголовков и запустите вторую проверку по нему. Сам ответ с переадресацией почти не содержит заголовков безопасности — именно поэтому google.com получает 25/100.
- Кнопка «Копировать» кладёт весь отчёт в буфер обмена обычным текстом — URL, статус, оценку с буквой и каждый заголовок; это и вставляют в задачу трекера. Планируйте серийные проверки из расчёта двадцать запросов в минуту: сверх этого API отвечает 429, а страница показывает общее сообщение об ошибке.
Устранение неполадок
Страница показывает «Failed to check headers. Please verify the URL is accessible.», хотя сайт открывается в браузере как обычно.
Это общее сообщение появляется, когда ответ вернулся непригодным. Чаще всего срабатывает ограничение частоты: если с одного адреса сделать больше двадцати проверок в минуту, API отвечает 429 Too Many Requests. Подождите минуту и повторите. То же сообщение появляется, когда сервер отвечает на HEAD-запрос дольше десятисекундного тайм-аута.
В строке ошибки написано «Connection failed: SSL certificate problem: certificate has expired».
Сертификат проверяется, а не принимается вслепую, поэтому просроченный, самоподписанный или выданный на другое имя хоста сертификат останавливает проверку вместо того, чтобы выдать вводящий в заблуждение отчёт. Обновите или исправьте сертификат либо проверьте адрес по http://, чтобы прочитать заголовки, которые сервер отдаёт до установления TLS.
В строке ошибки написано «Internal URLs not allowed», «Private IPs not allowed» или «This port is not allowed».
Инструмент отклоняет localhost, частные и зарезервированные диапазоны IP, точки доступа к метаданным облака и порты 22, 23, 25, 3306, 5432, 6379, 11211, 27017, 8080 и 8443, чтобы его нельзя было превратить в сканер внутренней сети. Используйте публично разрешаемое имя хоста на порту 80 или 443; для локального сервера выполните curl -I прямо на этой машине.
Карточка «Код статуса» показывает 301 или 302, лишь несколько заголовков и низкую оценку безопасности.
Переадресации намеренно не отслеживаются, поэтому вы оцениваете сам ответ с переадресацией, а не конечную страницу. google.com отвечает 301 с location: https://www.google.com/ и именно поэтому получает 25/100. Скопируйте значение location из таблицы заголовков и запустите вторую проверку по нему, чтобы оценить страницу, на которую действительно попадают посетители.
В строке ошибки написано «Connection failed: Could not resolve host».
Наш сервер не нашёл публичной DNS-записи для этого имени хоста. Проверьте написание, удалите пробел или кавычку, попавшие в адрес при вставке, и убедитесь, что домен разрешается за пределами вашей сети. Хост, который существует только в вашем файле hosts, за VPN или на внутреннем DNS-сервере, отсюда недостижим.
Часто задаваемые вопросы
Введите домен в поле в верхней части страницы и нажмите Enter или кнопку «Проверить». Наш сервер отправит HEAD-запрос по этому URL, и страница заполнит три карточки — «Код статуса», «Оценка безопасности» и «Время ответа», — а следом покажет разбор «Заголовки безопасности» и таблицу всех полученных заголовков. github.com отвечает 200 OK примерно за 60 мс и присылает 17 полей. Расширения, команда curl и инструменты разработчика не нужны.
HTTP-заголовок — это строка вида «имя: значение», которая описывает запрос или ответ. content-type: text/html; charset=utf-8 сообщает тип содержимого, cache-control — как долго ответ можно переиспользовать, location — адрес переадресации. RFC 9110, HTTP Semantics, задаёт синтаксис полей и реестр их имён. Заголовки идут рядом с телом сообщения, а не внутри него; на этой странице перечислены только заголовки ответа.
Здесь оцениваются семь: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy и Permissions-Policy. HSTS и CSP весят по 20 баллов, X-Content-Type-Options и X-Frame-Options — по 15, оставшиеся три — по 10. MDN помечает X-XSS-Protection как устаревший и нестандартный и советует вместо него надёжную Content-Security-Policy, так что эти десять баллов стоит считать наследием, а не целью.
Запустите проверку и прочитайте раздел «Заголовки безопасности»: у каждого из семи есть отметка Present или Missing, однострочное описание и, если заголовок есть, точное значение от сервера. Карточка «Оценка безопасности» переводит это в шкалу 0–100 с буквой: от 90 — A+, от 80 — A, от 70 — B, от 60 — C, от 40 — D, ниже 40 — F. github.com набирает 90/100, не хватает только Permissions-Policy.
Нажмите F12, откройте вкладку «Сеть», перезагрузите страницу, щёлкните по запросу документа и прочитайте панель заголовков ответа. Там видно то, что получил именно ваш браузер, включая cookie и согласование содержимого. Эта страница — нейтральная альтернатива: запрос уходит с нашего сервера с идентификатором FreeWebTools Header Checker/1.0 и без cookie, поэтому вы видите ответ для анонимного посетителя.
Заголовки несут всё, что в сообщении не является телом: исход передачи, тип содержимого и кодировку, правила кэширования и перепроверки, cookie и политики безопасности, которые обязан применить браузер. Без content-type браузеру приходится угадывать формат, без strict-transport-security он может продолжать работать по обычному HTTP, без content-security-policy внедрённый скрипт выполнится беспрепятственно. Одно тело сообщения ничего из этого выразить не может.
Каждое поле занимает одну строку: имя, двоеточие, необязательный пробел и значение — например, x-frame-options: deny. RFC 9110, раздел 5.1, делает имена полей нечувствительными к регистру, а HTTP/2 требует их в нижнем регистре, поэтому в таблице выше стоит content-type, а не Content-Type. Поле может законно повторяться; в этом случае инструмент сохраняет последнее разобранное значение.
Да. TLS шифрует всё HTTP-сообщение вместе с заголовками, поэтому наблюдатель в сети видит IP-адрес назначения и имя хоста в SNI, но не имена полей, значения или cookie. По обычному HTTP не защищено ничего — именно для этого нужен Strict-Transport-Security: RFC 6797 предписывает браузеру использовать HTTPS для этого хоста в течение всего срока max-age, а сам заголовок браузеры игнорируют, если он пришёл по HTTP.
Имена полей — нет. RFC 9110, раздел 5.1, утверждает, что имена полей нечувствительны к регистру: Content-Type и content-type — одно и то же поле, а HTTP/2 предписывает нижний регистр. Со значениями иначе: браузер одинаково примет x-frame-options: DENY и deny, но URL в location, ETag или nonce внутри Content-Security-Policy сравниваются ровно так, как записаны.
Нет. Эта страница показывает заголовки ответа, потому что запрос отправляет наш сервер, а не ваш браузер. Чтобы прочитать заголовки, которые шлёт ваш браузер, откройте инструменты разработчика, перейдите на вкладку «Сеть» и разверните заголовки запроса либо воспользуйтесь сервисом-эхом. Всё, что показано здесь, — статус, оценка и таблица — описывает введённый сайт, а не ваш клиент.