Cybersecurity glossary
What is CSP strict-dynamic?
Learn what CSP strict-dynamic does, how nonce or hash trust propagates to script-loaded scripts, how it changes host allowlists, and how to adopt it without breaking apps.
Definition
CSP strict-dynamic is a script-src keyword that tells supporting browsers to trust scripts dynamically created by already-trusted scripts—typically those allowed via a nonce or hash—while ignoring most static host allowlists for script loading in that policy.
Why strict-dynamic matters
Modern frontends load scripts dynamically: tag managers, module loaders, A/B tools, and framework chunks. Maintaining an accurate script-src host allowlist becomes endless—and often insecure when people add https: wildcards. 'strict-dynamic' shifts trust from hosts to a small nonce/hash root that may spawn additional scripts.
Used correctly, it makes strict CSP compatible with real-world JavaScript loading.
How strict-dynamic works
Establish a root of trust
Allow a bootstrap script with a nonce or hash.
Enable strict-dynamic in script-src
Supporting browsers propagate trust to scripts created by trusted scripts.
Ignore most host allowlists
In those browsers, parser-inserted host allowlisting largely stops being the trust model.
Keep legacy fallbacks if needed
Older browsers may still use host lists you leave for compatibility.
Block unauthenticated inline injection
Injected script tags without nonce/hash remain blocked.
What changes in policy design
From hosts to roots
Focus engineering effort on nonce/hash plumbing instead of endless CDN domains.
Dynamic loaders welcome
Trusted bootstraps can create script elements for later chunks.
Wildcards lose appeal
Broad https: allowlists are no longer the path of least resistance.
Compatibility dual policy
Many deployments include both strict-dynamic and temporary host fallbacks.
Adoption pitfalls
| Pitfall | Result | Fix |
|---|---|---|
| strict-dynamic without nonce/hash root | Legitimate scripts fail or policy is ineffective | Ship nonces/hashes first |
| Relying on event handler attributes | Inline handlers blocked under strict CSP | Move to addEventListener in external/nonce scripts |
| Keeping unsafe-inline | XSS containment collapses | Remove unsafe-inline after migration |
| Trusting attacker-controlled script URLs in a trusted loader | Trusted loader becomes a gadget | Sanitize loader inputs; lock destinations |
Rollout checklist
- Implement per-response nonces or stable hashes for bootstrap scripts.
- Add 'strict-dynamic' to script-src in supporting browsers.
- Retain temporary host fallbacks only for documented legacy clients.
- Eliminate inline event handlers and javascript: URLs.
- Remove unsafe-inline once reports are clean.
- Audit dynamic script loaders for open URL redirection into script src.
- Use Report-Only during migration.
- Retest tag managers and third-party embeds after enabling strict-dynamic.
The practical takeaway
CSP 'strict-dynamic' lets trust flow from nonce- or hash-approved scripts to the scripts they load, reducing dependence on fragile host allowlists. It is a cornerstone of modern strict CSP for dynamic applications.
Start with a solid nonce/hash root, add 'strict-dynamic', clean up unsafe inline patterns, and treat any trusted loader that accepts arbitrary URLs as a high-risk gadget.
Related security terms
Frequently asked questions
What does strict-dynamic mean?
It means scripts that are already trusted (via nonce/hash) may load additional scripts, and those children are also trusted—without relying on a big host allowlist.
Do I still need host allowlists with strict-dynamic?
In supporting browsers, strict-dynamic causes most host allowlists in script-src to be ignored. You may keep hosts for older browsers as a fallback pattern.
What is the root of trust?
Usually a nonce- or hash-allowed bootstrap script. Without a strong root, strict-dynamic does not help.
Can attackers abuse strict-dynamic?
If they can already run a trusted script or manipulate how trusted scripts load URLs, risk remains. Strict-dynamic reduces reliance on fragile host lists; it is not magical XSS immunity.
Does strict-dynamic allow eval?
No. unsafe-eval is a separate concern and should still be avoided.
How should teams roll it out?
Adopt nonces/hashes first, add strict-dynamic, test modern browsers, keep temporary fallbacks for legacy clients, then remove unsafe-inline and overly broad hosts.
Is strict-dynamic required for good CSP?
Not required, but it is a key ingredient in widely recommended strict CSP recipes for applications with dynamic script loading.
References
Explore authoritative guidance and frameworks related to csp strict-dynamic.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.