strict-dynamic in script-src
Why it matters
Without 'strict-dynamic', every module your bundler or runtime loads dynamically must be individually allowlisted in CSP. In practice this means developers add 'unsafe-inline' or broad domain wildcards as a shortcut, silently destroying XSS protection. 'strict-dynamic' delegates trust from an allowlisted script (identified by nonce or hash) to every script it loads — removing the need for individual allowlisting of dynamic imports. CWE-79 and CWE-693 both apply: the absence forces teams toward CSP configurations that the OWASP A03 guidance explicitly flags as ineffective for modern SPAs and module-heavy codebases.
Severity rationale
High because omitting `'strict-dynamic'` forces a choice between a broken CSP that blocks legitimate dynamic imports and a weakened one that uses unsafe fallbacks, both of which undermine XSS protection.
Remediation
Add 'strict-dynamic' alongside your nonce in script-src. This single keyword makes dynamically loaded modules inherit trust from the bootstrapping script without requiring per-module allowlisting.
Content-Security-Policy: script-src 'nonce-{perRequestValue}' 'strict-dynamic'; object-src 'none'; base-uri 'self'
When 'strict-dynamic' is present, browsers automatically ignore domain allowlists and 'unsafe-inline' in supporting browsers — you can include them as fallbacks for older browsers without weakening policy. Do not pair 'strict-dynamic' with 'unsafe-inline' unless a nonce is also present; the nonce causes conforming browsers to ignore 'unsafe-inline' automatically.
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 Security Headers II Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-79
- cwe · CWE-693
- owasp:2021 · A03
Taxons
History
- 2026-04-18·v1.0.0·Initial import from security-headers-ii·automated