Security headers · Check
CSP allows 'unsafe-eval' — removing dynamic code execution
Your CSP includes `'unsafe-eval'` in `script-src` (or `default-src`). That permits `eval()`, `new Function()`, and similar dynamic code execution paths — both for your own code and for anything an attacker can inject through a payload that ends up in `eval`.
Why it matters
Audit which dependencies need eval (older templating engines, some legacy bundlers) and migrate to a build-time alternative. Then drop `'unsafe-eval'`. The result is a CSP that genuinely blocks runtime code synthesis.
Real-world risk
'unsafe-eval' permits eval(), Function(), and similar dynamic execution — a common path for converting an injected string into running JavaScript.
Fix steps (in order)
- Audit dependencies to find what requires eval (older templating engines, some bundlers).
- Migrate to a build-time alternative (precompiled templates, modern bundlers without runtime eval).
- Remove 'unsafe-eval' from script-src once the audit is clean.
Topic explainer
What is Content Security Policy (CSP)? A practical explainer →
An accessible explanation of Content Security Policy: what it does, why it exists, the directives that matter, and how to roll one out without breaking your app.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (csp_unsafe_eval) clears once the externally-observable signal is in place.