A Content Security Policy contains unsafe-eval
In the reportCSP allows 'unsafe-eval' in script sources
csp_unsafe_eval_allowed · Review item
This security advice appears when one captured Content Security Policy lists 'unsafe-eval' for scripts. Under that policy, the token can permit text-to-code calls such as eval(); another enforcing policy may still block them. Remove the token once your scripts no longer need it.
Severity: Notice. Security advice in Good to know. Review the keyword when scripts can work without it; another enforcing policy may still restrict eval, and this check makes no ranking claim.
Why it matters
web.dev's guide to a strict policy notes that 'unsafe-eval' can leave injections into eval(), setTimeout() and a few other APIs possible under that policy. Another enforcing policy may restrict them further.
What to do
- Look at the finding: it shows the policy, the script directive we judged and up to ten pages that send it.
- Find which of your scripts or libraries passes code as text to
eval()or a similar call; many have an alternative. - Remove
'unsafe-eval'fromscript-src, or fromdefault-srcif the policy has noscript-src.
When to leave it as it is: if a library you rely on still needs eval() and has no alternative yet, you can leave it and plan the change; the check does not see whether eval is actually used.
What we read
We read the enforcing policies of each crawled page with our own user agent: each policy in a Content-Security-Policy response header, and a CSP <meta> tag inside <head>. Report-only headers are not read. Each policy is judged on its own, as it is written, not combined with the page's other policies the way a browser applies them.
In a policy we take script-src, or default-src when there is no script-src, and report the policy when that directive contains 'unsafe-eval'. 'wasm-unsafe-eval' does not count, and the keyword in another directive is not read.
Pages that send the same policy text are reported together, one finding per exact text; a policy that carries a new nonce on every response gives each page a finding of its own. Pages whose headers or HTML were not captured in full are not judged.
Example & evidence
Illustrative example — one policy, not a live audit.
https://bakery.example/menu/ sends:
Content-Security-Policy: default-src 'self' 'unsafe-eval'There is no script-src, so default-src applies to scripts, and it allows 'unsafe-eval'. The policy is reported.
Content-Security-Policy: default-src 'self'A possible correction, once no script needs eval(): the same policy without the keyword.
Confirm & check again
Check for yourself: open the page's response headers and look for 'unsafe-eval' in script-src, or in default-src if there is no script-src.
Check again: Full audit — run a new full audit. With complete coverage, this policy-text finding closes only when no currently crawled page sends the same flagged policy text; a new page using the old text keeps it open. Removing the keyword changes the text; a new policy that still lists unsafe-eval can open another finding.
Limits & sources
Each policy is judged alone: a second enforcing policy that blocks eval does not clear the finding, although a browser applies both. The check reads the declaration only and does not see whether any script calls eval().
Confidence: High because the policy text is read directly.
Sources
- web.dev, Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP) — notes that with unsafe-eval, injections into eval(), setTimeout() and a few other rarely used APIs remain possible, and that the keyword makes a policy slightly less secure. Checked 28 September 2026.
Editorial review: 2 November 2026