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 після розгортання.