Аналізатор 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	Ідентифікує 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
Сила політики стилів	небезпечні вбудовані стилі, надто широкі джерела, відсутність шляху міграції до nonces/hashes де це можливо
Захист від фреймінгу та клікджекингу	Відсутні або слабкі обмеження фреймів (часто через 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 та заголовки лише для звітування від повного набору заголовків.

Windows (PowerShell)

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

$r = Invoke-WebRequest -Uri https://example.com -Method Head; $r.Headers['Content-Security-Policy']; $r.Headers['Content-Security-Policy-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 та ітеруючи на основі порушень.

Виявити наявність політики лише для звітування
Зрозуміти, що буде заблоковано перед застосуванням
Експортувати звіт для плану впровадження та завдань

Налагодження зламаних скриптів, iframe або сторонніх віджетів

Надто суворий CSP може блокувати аналітику, вбудовування або API-з'єднання. Використовуйте аналізатор, щоб побачити, що дозволяє політика, і де вам можуть знадобитися явні джерела.

Підтвердити дозволені джерела для script/img/connect/frame
Виявити надто широкі маски (wildcards), додані як швидке виправлення
Замінити широкі дозволи на цільові домени

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

Створіть узгоджений звіт про поточний стан CSP для перевірок безпеки, анкет клієнтів або внутрішньої відповідності.

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

❓ Frequently Asked Questions

❓Що таке CSP і від чого воно захищає?

Політика безпеки контенту (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-заголовок?

Так. Крайові шари можуть додавати, об'єднувати або перевизначати заголовки. Якщо щось виглядає невідповідним, увімкніть сирі заголовки та слідуйте за редіректами, щоб перевірити кінцеві заголовки відповіді.

❓Чи є CSP заміною виправлення багів XSS?

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

❓Чи безпечно вставляти сюди URL-адреси?

Інструмент робить запити на стороні сервера до наданої URL-адреси та блокує цілі в приватних мережах. Уникайте розміщення секретів у URL-адресах (наприклад, токенів у рядках запиту) та віддавайте перевагу публічним 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 або додатку.