Анализатор CSP

Анализируйте Content-Security-Policy (CSP) и Content-Security-Policy-Report-Only для любого URL. Обнаруживайте рискованные директивы (unsafe-inline, wildcards), отсутствие стратегий nonce/hash, устаревшие шаблоны и получайте практические рекомендации для усиления защиты от XSS. Поддерживает редиректы, просмотр сырых заголовков, фильтрацию, вывод результатов и экспорт в JSON/PDF.

Loading…

О проекте Анализатор CSP

Вставьте URL для проверки его CSP-заголовков и быстро оцените, действительно ли политика защищает вас от XSS и инъекций. Этот анализатор выделяет опасные разрешения (например, unsafe-inline или широкие wildcards), объясняет, чего не хватает (стратегия nonce/hash, ограничения фреймов), и помогает перейти к практической, готовой к развертыванию CSP, безопасно используя report-only.

Возможности

Обнаружение и объяснение заголовков Content-Security-Policy и Content-Security-Policy-Report-Only.
Выявление типичных проблем CSP: unsafe-inline, unsafe-eval, широкие wildcards и излишне разрешительные источники.
Рекомендации по безопасному выполнению скриптов и стилей через стратегии nonce и hash.
Определение отсутствующих директив, важных для реального усиления защиты (например, frame-ancestors, object-src, base-uri).
Анализ Report-Only: понимание того, что было бы заблокировано, и как внедрить CSP, не нарушая работу продакшена.
Следование редиректам (до 10) для анализа итоговой политики, применяемой браузерами.
Просмотр сырых заголовков для точного вывода сервера и отладки.
Результаты + оценочная карта с фильтрацией «только проблемы».
Экспорт анализа в JSON или PDF для аудитов, задач и проверок безопасности.
Осведомленность об устаревших заголовках для выявления унаследованных политик и потребностей в миграции.

🧭 Как использовать for csp-analyzer

Введите URL для анализа

Вставьте URL страницы, которую хотите проверить (часто это главная страница или оболочка приложения).

Включите следование редиректам при необходимости

Оставьте «Следовать редиректам» включенным, чтобы анализатор достиг конечного HTTPS/www/локального назначения, где возвращается настоящий CSP.

Ознакомьтесь с оценочной картой и результатами

Начните с результатов, чтобы выявить критические риски (unsafe-inline, wildcards, отсутствующие ограничения) и понять, какие директивы влияют на оценку.

Проверьте сырые заголовки при отладке

Включите «Показать сырые заголовки», чтобы проверить точные имена/значения заголовков (полезно, если присутствует несколько CSP-заголовков или их изменяет прокси/CDN).

Экспортируйте отчет для вашего процесса безопасности

Скачайте JSON для автоматизации или PDF для аудитов безопасности и инженерных задач.

Технические характеристики

Модель запроса

Этот инструмент выполняет проверку заголовков URL и фокусируется на анализе заголовков безопасности, включая политики CSP и report-only.

Настройка	Поведение	По умолчанию
Следовать редиректам	Следует по цепочке редиректов для анализа фактической политики, возвращаемой конечным URL	Включено
Макс. редиректов	Ограничение редиректов для предотвращения зацикливания	10
Таймаут	Лимит времени ожидания запроса	15000 мс
User-Agent	Идентифицирует пользовательский агент запроса	Encode64Bot/1.0 (+https://encode64.com)
Частные сети	Блокирует доступ к диапазонам частных сетей в целях безопасности	Отключено (частные сети не разрешены)

Проверяемые CSP-заголовки

Анализатор проверяет как принудительные, так и нефоративные политики и представляет их в удобочитаемом виде.

Заголовок	Значение
Content-Security-Policy	Принудительная политика, применяемая браузером
Content-Security-Policy-Report-Only	Неблокирующая политика, сообщающая о нарушениях (полезна для внедрения и настройки)

Сайты могут отправлять несколько CSP-заголовков. Браузеры применяют правила комбинирования/приоритета, которые могут быть сложными — исходные заголовки помогают подтвердить, что именно отправляется.

Что ищет анализ

Результаты основаны на практических проверках усиления CSP и типичных ошибках развертывания.

Область	Примеры обнаруженного
Надёжность политики скриптов	использование unsafe-inline / unsafe-eval, источники с подстановочными знаками, отсутствие стратегии nonce/hash
Надёжность политики стилей	небезопасные встроенные стили, слишком широкие источники, отсутствие пути миграции к nonce/hash там, где это возможно
Защита от фреймов и кликджекинга	Отсутствующие или слабые ограничения фреймов (часто через frame-ancestors)
Устаревшие / нерекомендуемые шаблоны	Старые директивы или шаблоны, которые следует модернизировать
Готовность к внедрению	Видимость отчётов и конечных точек Report-Only

Командная строка

Используйте эти команды для быстрой проверки CSP-заголовков. Они полезны для валидации данных, которые показывает анализатор.

macOS / Linux

Получить заголовки ответа (искать CSP)

curl -I https://example.com

Проверьте заголовки Content-Security-Policy и Content-Security-Policy-Report-Only в ответе.

Следовать редиректам при проверке заголовков

curl -IL https://example.com

Гарантирует, что вы увидите CSP-заголовки от конечного назначения (HTTPS, www, маршрут оболочки приложения).

Показать только CSP-заголовки (регистронезависимый поиск)

curl -I https://example.com | grep -i "content-security-policy"

Быстро изолирует CSP и заголовки report-only из полного набора заголовков.

Windows (PowerShell)

Проверить CSP-заголовки

$r = Invoke-WebRequest -Uri https://example.com -Method Head; $r.Headers['Content-Security-Policy']; $r.Headers['Content-Security-Policy-Report-Only']

Отображает основные и report-only CSP-заголовки, если они присутствуют.

Сначала разверните новые политики в режиме Report-Only, изучите отчёты о нарушениях, затем ужесточите и примените их. Настройка CSP — это итеративный процесс для современных приложений.

Примеры использования

Усилить защиту сайта от XSS

Используйте CSP, чтобы снизить влияние уязвимостей инъекций, ограничивая источники загрузки скриптов/стилей и обработку встроенного кода.

Выявить unsafe-inline/unsafe-eval и спланировать переход на nonces/hashes
Ограничить script-src/style-src доверенными источниками
Добавить недостающие защитные директивы (base-uri, object-src, frame-ancestors)

Безопасное внедрение CSP с Report-Only

Постепенно внедряйте CSP, не нарушая работу продакшена, начиная с Content-Security-Policy-Report-Only и итеративно исправляя нарушения.

Обнаружить наличие политики report-only
Понять, что будет заблокировано, до принудительного применения
Экспортировать отчёт для плана внедрения и задач

Отладка сломанных скриптов, iframe или сторонних виджетов

Слишком строгий CSP может блокировать аналитику, встраиваемые элементы или API-подключения. Используйте анализатор, чтобы увидеть, что разрешает политика и где могут потребоваться явные источники.

Подтвердить разрешённые источники для script/img/connect/frame
Обнаружить слишком широкие wildcard-правила, добавленные как быстрое решение
Заменить широкие разрешения на целевые домены

Проверка безопасности / доказательства соответствия

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

Скачать JSON для отслеживания изменений во времени
Скачать PDF для артефактов аудита и обмена

❓ Frequently Asked Questions

❓Что такое CSP и от чего он защищает?

Content Security Policy (CSP) — это уровень безопасности, применяемый браузером, который ограничивает источники загрузки ресурсов и способы выполнения скриптов/стилей. В основном используется для снижения воздействия межсайтового скриптинга (XSS) и инъекционных атак.

❓В чём разница между CSP и CSP Report-Only?

Content-Security-Policy применяется принудительно (может блокировать). Content-Security-Policy-Report-Only не блокирует; он сообщает о нарушениях, чтобы вы могли настроить политику перед её применением.

❓Почему unsafe-inline считается опасным?

unsafe-inline разрешает встроенные скрипты и стили, что ослабляет способность CSP останавливать внедрённый код. Более безопасные подходы используют nonce или хеши, чтобы разрешать только известные встроенные блоки, по-прежнему блокируя неожиданные инъекции.

❓Нужны ли мне nonce или хеши?

Если ваше приложение использует встроенные скрипты или стили, nonce/хеши — это современный способ сохранить эффективность CSP, не нарушая функциональность. Они разрешают определённые встроенные блоки, предотвращая произвольные инъекции.

❓Могут ли CDN или прокси изменить мой CSP-заголовок?

Да. Пограничные слои могут добавлять, объединять или переопределять заголовки. Если что-то выглядит несогласованным, включите raw-заголовки и следите за редиректами, чтобы проверить итоговые заголовки ответа.

❓Является ли CSP заменой исправления XSS-багов?

Нет. CSP — это элемент защиты в глубину. Вам по-прежнему нужны правильное экранирование вывода, безопасные шаблоны и валидация ввода. CSP уменьшает радиус поражения, если что-то проскользнёт.

❓Безопасно ли вставлять сюда URL-адреса?

Инструмент выполняет серверные запросы к предоставленному URL и блокирует цели в частных сетях. Избегайте размещения секретов в URL (например, токенов в query-строках) и предпочитайте публичные URL, которым вы доверяете.

Pro Tips

Best Practice

Начните с Content-Security-Policy-Report-Only, соберите нарушения, затем ужесточите и примените. CSP для реальных приложений — итеративный процесс.

Best Practice

Замените unsafe-inline на стратегию с nonce или хешем. Держите политики явными и минимальными.

Best Practice

Добавьте frame-ancestors, чтобы снизить риск кликджекинга, и не полагайтесь только на устаревшие заголовки.

Best Practice

Избегайте широких масок в качестве быстрого решения. Предпочитайте целевые домены для скриптов/изображений/подключений и анализируйте потребности сторонних сервисов.

CI Tip

Экспортируйте JSON-отчёт и отслеживайте изменения CSP в CI, чтобы ловить регрессии при изменении заголовков из-за обновлений CDN или приложения.