No unsafe-eval
Why it matters
CWE-95 (Eval Injection) and CWE-79 both apply here: 'unsafe-eval' in an extension CSP enables eval(), new Function(), and setTimeout with string arguments, all of which can execute attacker-controlled strings as code. In an extension context, that code runs with chrome.* API access. OWASP A03 (Injection) covers this attack class. Chrome's own documentation states that 'unsafe-eval' should never appear in extension CSP; MV3 bans it entirely. Even in MV2, its presence typically indicates AI-generated or copy-pasted code that hasn't been refactored for the privilege model extensions require.
Severity rationale
Critical because `'unsafe-eval'` allows dynamic string execution in a privileged extension context, enabling any injected string to invoke `chrome.*` APIs directly.
Remediation
Remove 'unsafe-eval' from CSP and refactor every eval() and new Function() call to use static alternatives.
"content_security_policy": {
"extension_pages": "script-src 'self'; object-src 'none'"
}
For template rendering without eval, use document.createElement + .textContent rather than string-interpolated HTML. If a devtool panel needs to evaluate arbitrary user code, use a sandboxed iframe page — Chrome allows 'unsafe-eval' in sandboxed pages specifically.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Extension Permissions & Security Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-95 — Improper Neutralization of Directives in Dynamically Evaluated Code (Eval Injection)
- cwe · CWE-79 — Improper Neutralization of Input During Web Page Generation (XSS)
- owasp:2021 · A03
- external · chrome-csp-unsafe-eval — Chrome Extensions: Avoiding unsafe-eval
Taxons
History
- 2026-04-18·v1.0.0·Initial import from extension-permissions-security·automated