Content Security Policy містить unsafe-eval
У звітіCSP allows 'unsafe-eval' in script sources
csp_unsafe_eval_allowed · Потребує перегляду
Ця порада з безпеки з’являється, коли одна захоплена політика Content Security Policy перелічує 'unsafe-eval' для скриптів. За цією політикою токен може дозволяти виклики, що перетворюють текст на код, як-от eval(); інша чинна політика однаково може їх блокувати. Приберіть токен, щойно він більше не буде потрібен вашим скриптам.
Серйозність: До уваги. Порада з безпеки в розділі «Корисно знати». Перегляньте ключове слово, коли скрипти можуть працювати без нього; інша чинна політика може обмежувати eval, і перевірка не робить висновків про ранжування.
Чому це важливо
Посібник web.dev про сувору політику зазначає, що 'unsafe-eval' може залишити можливими впровадження в eval(), setTimeout() і кілька інших API за цією політикою. Інша чинна політика може обмежити їх додатково.
Що зробити
- Перегляньте знахідку: у ній показано політику, директиву скриптів, яку ми оцінили, і до десяти сторінок, що її надсилають.
- З’ясуйте, який із ваших скриптів чи бібліотек передає код як текст в
eval()чи подібний виклик; для багатьох є альтернатива. - Приберіть
'unsafe-eval'зіscript-srcабо зdefault-src, якщо політика не маєscript-src.
Коли залишити як є: якщо бібліотеці, на яку ви покладаєтеся, досі потрібен eval() і альтернативи ще немає, можна залишити як є й запланувати зміну; перевірка не бачить, чи eval справді використовується.
Що ми читаємо
Ми читаємо чинні політики кожної просканованої сторінки з власним user agent: кожну політику в заголовку відповіді Content-Security-Policy і CSP-тег <meta> усередині <head>. Заголовки лише для звітування не читаються. Кожна політика оцінюється окремо, так, як її записано, а не в поєднанні з іншими політиками сторінки, як їх застосовує браузер.
У політиці ми беремо script-src або default-src, коли script-src немає, і фіксуємо політику, коли ця директива містить 'unsafe-eval'. 'wasm-unsafe-eval' не враховується, а ключове слово в іншій директиві не читається.
Сторінки, що надсилають однаковий текст політики, фіксуються разом, одна знахідка на точний текст; політика, яка має новий nonce у кожній відповіді, дає кожній сторінці власну знахідку. Сторінки, заголовки чи HTML яких захоплено не повністю, не оцінюються.
Приклад і докази
Ілюстративний приклад — одна політика, а не реальний аудит.
https://bakery.example/menu/ надсилає:
Content-Security-Policy: default-src 'self' 'unsafe-eval'Директиви script-src немає, тому до скриптів застосовується default-src, а вона дозволяє 'unsafe-eval'. Політика фіксується.
Content-Security-Policy: default-src 'self'Можливе виправлення, щойно жодному скрипту не буде потрібен eval(): та сама політика без цього ключового слова.
Підтвердити й перевірити знову
Перевірте самі: відкрийте заголовки відповіді сторінки й пошукайте 'unsafe-eval' у script-src або в default-src, якщо script-src немає.
Повторна перевірка: Повний аудит — запустіть новий повний аудит. За повного охоплення перевірки ця знахідка про текст політики закривається, лише коли жодна наразі просканована сторінка не надсилає того самого позначеного тексту політики; нова сторінка зі старим текстом залишає її відкритою. Видалення ключового слова змінює текст; нова політика, яка досі перелічує unsafe-eval, може відкрити ще одну знахідку.
Обмеження та джерела
Кожна політика оцінюється окремо: друга чинна політика, що блокує eval, знахідки не знімає, хоча браузер застосовує обидві. Перевірка читає лише декларацію й не бачить, чи якийсь скрипт викликає eval().
Упевненість: Висока, бо текст політики зчитується безпосередньо.
Джерела
- web.dev, Як зменшити ризик міжсайтового скриптингу (XSS) за допомогою суворої Content Security Policy (CSP) — зазначає, що з unsafe-eval впровадження в eval(), setTimeout() і кілька інших рідко вживаних API залишаються можливими і що це ключове слово робить політику трохи менш безпечною. Перевірено 28 вересня 2026.
Редакційна перевірка: 2 листопада 2026