Почему каждый пятый новый сайт выходит без единого защитного заголовка и как это исправить

Перед запуском продукта вы проверяете всё: скорость, вёрстку, метрики, платежи. А что получит браузер первого посетителя с точки зрения безопасности? Чаще всего — пустоту.

Я провёл пассивную проверку 100 свежезапущенных продуктов: смотрел только публичные HTTP-заголовки и HTML главной страницы — ровно то, что видит любой сканер или потенциальный клиент. Никакого взлома, никаких попыток авторизации, просто загрузка страницы, как у обычного пользователя.

Результат: у 20 из 100 не оказалось ни одного базового защитного заголовка. И только 13 сайтов были полностью чистыми. Остальным есть что чинить.

Что значат эти заголовки и почему они так важны

Защитные HTTP-заголовки — это инструкции, которые сервер отправляет браузеру вместе с ответом. Без них сайт молча разрешает скриптам, фреймам и сторонним запросам делать почти всё, что угодно.

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

Почему это повторяется от запуска к запуску

Ни один из этих заголовков не требует писать код. Это настройки уровня хостинга или CDN: у Vercel, Netlify, Cloudflare и nginx есть готовые сниппеты, почти всё применяется на периферии без деплоя. Проблема не в квалификации.

Запуск — это сотня разных дел, и «заголовки» оказываются в списке на 101-м месте. Нет теста, который падал бы, нет деплоя, который ломался, нет пользователя, который жаловался. Сайт просто тихо говорит браузеру: «правил нет, делай что хочешь». Вот и получается, что проверка не происходит никогда.

Именно поэтому такую проблему ловит только автоматическая проверка — человек не способен помнить о заголовках каждый раз.

Как быстро это чинится: пример из жизни

Мне возражали: «Кто же будет возиться с этим во время запуска?» Но один из найденных мной проектов — как раз с проблемами — исправил все шесть заголовков за 24 часа. Я перепроверил после: с 5 находок до нуля. Не потребовалось ни одной ночной смены.

Если ваш сайт за Cloudflare, четыре из шести заголовков — это одно Transform Rule (Modify Response Header) на периферии. Без изменения кода, без деплоя. HSTS начинается с короткого max-age (например, 3600) и увеличивается после проверки. С CSP сложнее — для SPA нужно аккуратно прописать default-src 'self' и домены API, но можно начать с режима Content-Security-Policy-Report-Only, чтобы увидеть, что ломается, прежде чем включать жёсткое правило.

Чек-лист перед запуском

• Проверьте свои заголовки: curl -I ваш-сайт или онлайн-сканер. Смотрите на шесть пунктов из таблицы.
• Начните с X-Frame-Options, X-Content-Type-Options и Referrer-Policy — это одна строка в конфиге.
• Подключите HSTS хотя бы с коротким max-age, потом усилите.
• Для CSP используйте Report-Only на страницах, где сложно предсказать ресурсы.
• Не верьте, что «у команды больше людей» — проверка показывает, что большие команды чаще проваливаются.

Ошибка — думать, что это можно отложить на потом. После запуска трафик уже идёт, и каждый беззащитный ответ уходит в браузеры реальных пользователей.

Запуск не завершён в момент, когда деплой прошёл успешно. Он завершён, когда то, что получает браузер незнакомого человека, проходит базовую проверку. 87 из 100 проверенных сайтов не прошли такую проверку. Ваш может стать исключением — на это уйдёт меньше часа.