CSP дозволяє надто широкі джерела скриптів чи об’єктів

Чому це важливо

Посібник web.dev про сувору політику для скриптів пояснює, що списки хостів можна обійти в багатьох конфігураціях, і рекомендує nonce чи хеші з 'strict-dynamic'. Широкий токен джерела в script-src чи object-src варто переглянути в цій політиці, навіть якщо інша чинна політика може звузити фактичний дозвіл браузера.

Що зробити

Перегляньте знахідку: у ній показано політику, знайдені широкі джерела для скриптів чи об’єктів і до десяти сторінок, що її надсилають.
Замініть їх хостами, з яких ви справді завантажуєте скрипти, задайте object-src 'none', якщо не використовуєте плагінів, або переведіть скрипти на nonce чи хеші з 'strict-dynamic'.
Приберіть *, http:, https: і data: з script-src та object-src або з default-src, де цих директив немає.

Коли залишити як є: якщо широке джерело — це резерв поруч із 'strict-dynamic' і nonce чи хешем, його можна залишити: браузери, що підтримують 'strict-dynamic', його ігнорують, хоча перевірка однаково його фіксує.

Що ми читаємо

Ми читаємо чинні політики кожної просканованої сторінки з власним user agent: кожну політику в заголовку відповіді Content-Security-Policy і CSP-тег <meta> усередині <head>. Заголовки лише для звітування не читаються. Кожна політика оцінюється окремо, так, як її записано, а не в поєднанні з іншими політиками сторінки, як їх застосовує браузер.

У політиці ми беремо script-src і object-src, кожен з яких за відсутності спирається на default-src. Політика фіксується, коли будь-який із них містить *, http:, https: або data: у будь-якому регістрі літер. Шаблони хостів, як-от *.example.com, blob: та інші директиви, як-от style-src чи img-src, не фіксуються.

Сторінки, що надсилають однаковий текст політики, фіксуються разом, одна знахідка на точний текст; політика, яка має новий nonce у кожній відповіді, дає кожній сторінці власну знахідку. Сторінки, заголовки чи HTML яких захоплено не повністю, не оцінюються.

Приклад і докази

Ілюстративний приклад — одна політика, а не реальний аудит.

https://bakery.example/ надсилає:

Content-Security-Policy: script-src 'self' https:; object-src *

Ця політика перелічує всі джерела скриптів https: і * для об’єктів, тому перевірка фіксує обидва широкі токени. Інша чинна політика могла б звузити те, що справді завантажується.

Content-Security-Policy: script-src 'self' https://cdn.bakery.example; object-src 'none'

Можливе виправлення: назвіть один хост, з якого надходять скрипти, і вимкніть плагіни.

Підтвердити й перевірити знову

Перевірте самі: відкрийте заголовки відповіді сторінки й прочитайте script-src, object-src і default-src у Content-Security-Policy, шукаючи окреме *, http:, https: чи data:.

Повторна перевірка: Повний аудит — запустіть новий повний аудит. За повного охоплення перевірки ця знахідка про текст політики закривається, лише коли жодна наразі просканована сторінка не надсилає того самого позначеного тексту політики; нова сторінка зі старим текстом залишає її відкритою. Змінений текст оцінюється як новий текст політики й може створити ще одну знахідку, якщо широке джерело залишається.

Обмеження та джерела

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

Упевненість: Висока, бо текст політики зчитується безпосередньо.

Джерела

web.dev, Як зменшити ризик міжсайтового скриптингу (XSS) за допомогою суворої Content Security Policy (CSP) — пояснює, що політики, побудовані на списках хостів, можна обійти в більшості конфігурацій, і рекомендує nonce чи хеші зі strict-dynamic, зазначаючи, що браузери, які його підтримують, тоді ігнорують резервне https:. Перевірено 28 вересня 2026.

Редакційна перевірка: 2 листопада 2026

Політика скриптів оголошує unsafe-inline без nonce, хешу чи strict-dynamic — одна політика містить дієвий токен unsafe-inline для скриптів.
Політиці Content Security Policy бракує обмежень для об’єктів або базової адреси — політика нічого не каже про об’єкти плагінів чи базову адресу сторінки.

Content Security Policy перелічує широкі джерела скриптів чи об’єктів