Проверка заголовков безопасности

Заголовки безопасности помогают браузеру ограничивать загрузку ресурсов, передачу реферера и доступ к отдельным возможностям устройства. Вставьте ответ сервера, чтобы увидеть наличие CSP, HSTS, X-Content-Type-Options, Referrer-Policy и Permissions-Policy. Список — отправная точка для проверки конфигурации, а не «оценка безопасности сайта». Наличие заголовка с неправильным значением может быть хуже осмысленной постепенной настройки. Например, CSP с разрешением всех источников почти не ограничивает скрипты.

Внедряйте CSP через инвентаризацию реальных скриптов, стилей и внешних сервисов. Резкое включение запрета может сломать оплату, аналитику или личный кабинет. Для HSTS сначала убедитесь, что HTTPS стабильно работает на основном домене и нужных поддоменах; слишком широкая настройка усложняет откат. X-Content-Type-Options обычно требует значения nosniff. При проверке смотрите не только главную страницу, но и API, формы и статические файлы, если они обслуживаются разными слоями.

Вставьте заголовки ответа. Проверка покажет наличие CSP, HSTS, X-Content-Type-Options и других известных механизмов.

Начните с кнопки «Вставить пример», чтобы увидеть ожидаемый формат ввода. Затем замените демонстрационные значения своими данными в полях «Исходные данные». Нажмите «Получить результат». Если формат неверный, инструмент покажет ошибку на русском языке; исправьте исходные данные и повторите действие.

Готовый результат можно скопировать одной кнопкой или скачать в файл security-headers-report.txt. Проверьте итог перед публикацией на рабочем сайте: инструмент видит только переданные ему данные и не знает особенностей вашего проекта. Для больших выгрузок удобно сначала обработать небольшой фрагмент и убедиться, что структура результата подходит дальнейшему процессу.

Если CSP отсутствует, отчёт даст конкретную рекомендацию по её проектированию.

HTTP/2 200
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
content-security-policy: default-src 'self'

Пример показывает форму исходных данных. Результат создаётся только после запуска виджета, поэтому вы можете изменить пример и сразу увидеть, как это влияет на вывод. Если вы работаете с клиентским сайтом, используйте обезличенный образец для первой проверки, затем переходите к полному файлу.

Наличие заголовка не доказывает безопасность его значения. HSTS имеет смысл только на HTTPS и после проверки поддоменов.

Технически корректный результат ещё не означает, что он подходит бизнес-логике сайта. Например, URL может быть синтаксически верным, но вести на удалённую страницу; XML может быть хорошо сформированным, но не соответствовать настройкам конкретной площадки. После автоматической проверки откройте итог в целевой системе или браузере и сравните его с ожидаемым поведением.

Если инструмент сообщает об ошибке, начните с названного поля или строки. При обработке файлов проверьте кодировку, переносы строк, кавычки и спецсимволы. Они часто попадают в данные при экспорте из Excel, CMS или интеграции и могут менять смысл результата.

После правки конфигурации повторно получите заголовки с публичной точки, минуя локальный кэш. Сравните ответы 200, 3xx и 4xx: защитные заголовки могут исчезать на страницах ошибок. Если сайт стоит за Cloudflare или другим CDN, уточните, где именно добавляется политика — на origin или edge. Эта форма не отправляет вставленный ответ на Pugofka, поэтому подходит для анализа диагностического фрагмента, но не заменяет тестирование поведения браузера и полноценный аудит.

Для повторяющихся задач сохраните входной пример и ожидаемый результат как проверочный сценарий. После обновления сайта или формата данных прогоните его снова: небольшое изменение шаблона экспорта иногда меняет поведение без явной ошибки. Если результат используется в производственной системе, проверьте не только синтаксис, но и последствия на нескольких реальных записях. При публикации конфигурации или метатегов сравните исходный HTML и ответ сервера с тем, что вы видите в форме.

Для CSP составьте список нужных источников, а затем включайте ограничения постепенно. Если старый сайт использует встроенные скрипты, простое default-src self может сломать интерфейс. Смотрите отчёты нарушений и тестируйте формы, оплату, чат и аналитику. Не копируйте чужую политику целиком: разрешённые домены и небезопасные директивы могут не подходить вашему проекту. Этот виджет показывает наличие заголовка и его строку, но не исполняет страницу в браузере и не моделирует все пути загрузки ресурсов.

Для HSTS отдельно проверьте сертификат, редирект на HTTPS и все поддомены, прежде чем добавлять includeSubDomains или увеличивать срок. Ошибка на поддомене после включения строгой политики может сделать его недоступным для пользователей. При обслуживании страниц через CDN проверьте, не переписывает ли он заголовки приложения. После внедрения смотрите ответы на главной, в личном кабинете и на страницах ошибок: настройки могут отличаться. Тестируйте на staging, затем на проде с реальными заголовками.

Сохраните исходный пример и результат рядом с задачей, чтобы при следующем обновлении можно было повторить проверку. Откройте итоговый файл в целевой системе и сравните не только отсутствие ошибки, но и число обработанных записей, конечные адреса, отображение кириллицы и поведение на мобильном экране, если результат используется в интерфейсе. Для конфигурации сервера сначала примените изменения на тестовом окружении и выполните запрос к реальному URL. Для данных каталога выберите несколько контрольных SKU с разными ценами и остатками. Если расхождение найдено, исправляйте источник данных или шаблон генерации, а не только один скачанный файл. Так следующая автоматическая выгрузка не вернёт проблему.

Поля этого инструмента обрабатываются в вашем браузере. Содержимое не отправляется на сервер Pugofka, а локальный файл читается только после вашего выбора. Для XML определяется кодировка из объявления или BOM; при отсутствии подсказки сначала пробуется UTF-8, затем Windows-1251. Виджет скрыт от записи содержимого в Вебвизоре; в Яндекс Метрику передаются slug инструмента и тип действия — открытие, первое взаимодействие, запуск, получение результата, копирование или скачивание.

При копировании данные попадают в системный буфер обмена устройства, где их могут видеть другие приложения с соответствующим доступом. Если исходник содержит секреты или персональные данные, очистите поле после работы. Скачанный файл остаётся на устройстве, в выбранной браузером папке загрузок.

Используйте результат как рабочий черновик: вставьте его в конфигурацию, страницу или документ и повторно проверьте там, где он будет применяться. Если вы меняете индексируемые страницы, обновите связанные ссылки и карту сайта. Для миграции URL дополнительно запустите сетевую проверку редиректов, чтобы увидеть фактические HTTP-ответы после публикации.

Если задача связана с каталогом, импортом или поддержкой интернет-магазина, команда Pugofka может помочь встроить такую проверку в регулярный обмен данными и исправить источник ошибок. Одноразовая онлайн-утилита полезна для диагностики, а постоянный поток данных обычно требует автоматической проверки на стороне проекта.