No unsafe-eval in any CSP directive

'unsafe-eval' re-enables eval(), Function(), setTimeout(string), and setInterval(string) — the four JavaScript execution surfaces that an XSS payload needs to turn a reflected string into running code. With 'unsafe-eval' in CSP, an attacker who achieves any string injection can escalate directly to code execution, bypassing what would otherwise be a meaningful mitigation layer. CWE-79 and CWE-693 both apply. OWASP A03 (Injection) lists eval-style execution as a key XSS escalation path. The practical business impact is session hijacking, credential theft, or complete account takeover from a single injection point.

Remove 'unsafe-eval' from every CSP directive. Most modern libraries no longer require it — verify by checking your bundler output and library changelogs.

# Correct: no unsafe-eval
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{perRequest}' 'strict-dynamic'

If a specific library requires eval (older charting libraries, some template engines), isolate it in a Web Worker with a scoped CSP rather than enabling eval globally. As a last resort, document the unavoidable dependency with an inline comment and a remediation ticket — then scope 'unsafe-eval' to only the script-src directive rather than default-src.