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

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

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 — це правильна річ, на яку дивитись.