English Deutsch Español Français Italiano Nederlands Polski Українська
Security

HTTP Headers

Перегляд response-headers і аудит security-policies.

URL http or https (default https). Up to 3 redirects are followed.
Try: github.com cloudflare.com example.com mozilla.org
https://example.com/
Status: 200 HTTP/1.1 88 ms
F
Security grade?
Score
0 / 100
Status
200
Protocol?
HTTP/1.1
Latency?
88 ms
Security audit
  • fail Strict-Transport-Security? +0/25
    No HSTS header — a downgrade attack on a public Wi-Fi can redirect the user to plaintext HTTP.
  • fail Content-Security-Policy? +0/25
    No CSP — a single XSS bug can execute arbitrary scripts on this origin.
  • fail X-Frame-Options / frame-ancestors? +0/15
    Page can be framed by any site — vulnerable to clickjacking.
  • fail X-Content-Type-Options +0/10
    nosniff is missing — IE/old-Edge may execute disguised scripts based on content sniffing.
  • fail Referrer-Policy? +0/15
    No Referrer-Policy — full URLs (including query strings) leak to every clicked link.
  • fail Permissions-Policy? +0/10
    No Permissions-Policy — third-party iframes can request sensitive features without restriction.
Response headers
date: Sun, 26 Jul 2026 18:12:57 GMT content-type: text/html transfer-encoding: chunked connection: keep-alive server: cloudflare last-modified: Tue, 21 Jul 2026 07:16:00 GMT allow: GET, HEAD accept-ranges: bytes age: 9 cf-cache-status: HIT cf-ray: a21560248c6271cb-FRA
Що означає кожне поле?

Опис полів

Оцінка безпеки

Сумарний бал по заголовках безпеки, де HSTS і CSP важать найбільше. A+ — усі п'ять заголовків правильно налаштовані; F — жодного. Використовуйте оцінку як швидкий маркер, далі — деталі по кожному заголовку нижче.

HTTP-протокол

HTTP/1.1 — текстовий legacy-протокол. HTTP/2 мультиплексує стріми по одному TCP-з'єднанню (стиснення заголовків, server push). HTTP/3 — поверх QUIC (UDP), краще на нестабільних/мобільних мережах. Сучасний сервер має віддавати щонайменше HTTP/2.

Затримка

Round-trip від нашого сервера до цілі до першого байта відповіді. Це не CDN-бенчмарк — географічна відстань, TLS handshake і прогрів кешу всі впливають. Використовуйте як грубий сигнал свіжості, а не як production-метрику.

Ланцюжок редиректів

Довгий ланцюжок (3+ редиректи) шкодить SEO й перформансу. Класичний випадок — <code>http://example.com → https://example.com → https://www.example.com</code>: два стрибки, прийнятно. Більше п'яти — конфігураційна помилка.

Strict-Transport-Security (HSTS)

HSTS каже браузеру: "більше не з'єднуйся зі мною по plain HTTP". <code>max-age=15768000</code> (6 місяців) — практичний мінімум; <code>includeSubDomains; preload</code> опціонально включає у глобальний preload-list. Після preload не можна "вийти" протягом ~12 місяців — спершу налаштуйте все інше.

Content-Security-Policy (CSP)

CSP визначає, звідки можуть вантажитися script / style / image / frame. <code>default-src 'self'</code> — здоровий baseline; nonce-based <code>script-src</code> — найжорсткіший варіант. Уникайте <code>unsafe-inline</code> і <code>unsafe-eval</code> — вони нівелюють захист від XSS. Використовуйте report-uri / report-to для моніторингу.

X-Frame-Options

Поставте <code>DENY</code>, щоб заборонити фрейми взагалі, або <code>SAMEORIGIN</code> для дозволу лише same-origin. Сучасний еквівалент — <code>frame-ancestors</code> у CSP (багатше синтаксис) — будь-який із двох задовольняє наш audit.

Referrer-Policy

Контролює, що браузер шле у <code>Referer</code>. <code>strict-origin-when-cross-origin</code> (дефолт у сучасних браузерах) — гарний baseline: повний URL для same-origin, лише origin для cross-origin, нічого при downgrade. <code>no-referrer</code> прибирає взагалі; <code>unsafe-url</code> ллє повні URL — уникайте.

Permissions-Policy

Спадкоємець Feature-Policy. Дозволяє дозволити / заборонити браузерні API per-origin: <code>camera=(), microphone=(), geolocation=(self)</code>. Радше defense-in-depth; примусово застосовується до iframe — безпечніша поведінка для вбудованого контенту.

X-Content-Type-Options: nosniff

Без цього заголовка браузер може виконати JSON-відповідь як JavaScript, якщо "виглядає як код". <code>X-Content-Type-Options: nosniff</code> робить декларований Content-Type обов'язковим. Дешевий заголовок, завжди безпечно ввімкнути — немає вагомих причин не ставити.

Про цей інструмент

HTTP Headers завантажує вашу URL справжнім HTTPS-запитом, захоплює кожен заголовок у відповіді (та кожній проміжній відповіді на будь-якому redirect-ланцюзі) і прогонить результат через security-аудит, що покриває сучасні hardening-заголовки: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options / CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy та Permissions-Policy. Кожен заголовок перевіряється на присутність, осмисленість значення і best-practice-пропуски.

Окрім аудиту ми перелічуємо кожен заголовок дослівно, щоб ви могли підтвердити caching-політику (Cache-Control, ETag, Vary), CDN-трасування (CF-Ray, X-Cache, X-Served-By), компресію (Content-Encoding: br/gzip) та будь-які кастомні заголовки, що видає ваш стек. HTTP-метод (GET або HEAD), узгоджена HTTP-версія (HTTP/1.1, HTTP/2, HTTP/3) і TLS-версія повідомляються в request-барі.

Коли використовувати цей інструмент

  • Security-hardening. Перед запуском підтвердіть, що HSTS, CSP та решта виставлені з безпечними значеннями — Mozilla Observatory baseline як мінімум.
  • Cache-дебаг. Подивіться, який саме Cache-Control і Vary видає ваш CMS чи фреймворк — типова причина «стара версія застрягла».
  • Аудити redirect-ланцюгів. Виявляйте випадкові 302-then-301 ланцюги, HTTP-to-HTTPS-to-other-host петлі та брак канонікалізації.
  • Поведінка CDN. Підтвердіть, що Cloudflare/Fastly/CloudFront справді кешує те, що ви думаєте, прочитавши Age, X-Cache та CDN-специфічні заголовки.

Що покриває наш security-аудит

Для кожного з шести hardening-заголовків ми повідомляємо: присутній чи відсутній, фактичне значення та короткий вердикт («good», «needs tightening», «vulnerable»). HSTS без includeSubDomains, CSP з unsafe-inline або Referrer-Policy за дефолтом — маркуються. Ми ніколи не кажемо «ідеальну» політику, бо кожен сайт інший, але кажемо, які крутилки досі на заводських налаштуваннях.

Часті запитання

Що таке HSTS і чому це важливо?
Strict-Transport-Security каже браузеру «завжди використовуй HTTPS для цього домену, навіть якщо користувач набрав http:// або клікнув на http://-посилання». Виставлений з розумним max-age (зазвичай 31536000 = 1 рік), він запобігає SSL-stripping-атакам на наступних візитах. Додавання includeSubDomains розширює захист на кожен субдомен — сильний дефолт для більшості сайтів, але переконайтеся, що всі вони справді підтримують HTTPS.

Моя CSP відсутня — наскільки це небезпечно?
Без CSP будь-яка XSS-дірка на вашому сайті виконується на повну: може вивести cookies, завантажити attacker-controlled скрипти або переписати DOM. Стартова CSP default-src 'self' блокує найпоширеніші XSS-payloads (inline-скрипти, зовнішні script-завантаження) за майже нульовою ціною. Жорсткіші політики, що повністю забороняють inline-скрипти, вимагають рефакторингу, але дають значно сильніший захист.

Чи слідуєте за редиректами?
Так — до п'яти хопів. Кожен крок показано з його методом, статусом, location і заголовками, щоб ви могли виявити mixed-protocol хопи (HTTP→HTTPS), брак канонікалізації (apex vs www) або випадкові петлі. Більшість продакшн-сайтів мають редиректити максимум один раз (HTTP → HTTPS), потім віддавати контент; більше двох хопів — зазвичай ознака rewrite-правил, що перекриваються.

Чому інструмент показує HTTP/2, навіть коли я налаштував HTTP/3?
HTTP/3 (QUIC over UDP) вимагає, щоб клієнт opt-in через Alt-Svc-заголовок на першому коннекті. Наш checker використовує HTTP/2 over TCP за замовчуванням, як і більшість HTTP-клієнтів сьогодні; якщо ваш сервер анонсує HTTP/3 в Alt-Svc, ви побачите цей заголовок у результаті, але сама відповідь усе одно йде по HTTP/2. Присутність Alt-Svc — це правильна річ, на яку дивитись.