Content Security Policy (CSP)
Slap yourself if
You think CSP is just about blocking inline scripts or believe adding 'unsafe-inline' is a reasonable compromise.
Why this exists
Because CSP is one of the few defenses that actually limits blast radius after an injection — and most teams either misconfigure it into uselessness or deploy it without understanding the execution model it enforces.
Mental model
CSP is a runtime execution policy enforced by the browser. It constrains what code can execute and where it can load from, regardless of how the code got there.
- The browser parses CSP before executing page content.
- Every script, style, and resource load is checked against the policy.
- Violations are blocked at execution time, not filtered at input.
- The policy applies equally to injected and first-party code.
- Using CSP only as a reporting tool and never enforcing.
- Allowing broad sources that defeat the policy.
- Breaking apps by ignoring eval, inline scripts, or dynamic loaders.
- Assuming CSP fixes existing XSS vulnerabilities.
CSP is a browser-enforced execution policy that restricts where code and resources can load from, reducing the impact of injection vulnerabilities.
- Calls CSP an XSS sanitizer.
- Relies on unsafe-inline or unsafe-eval long-term.
- Cannot explain nonces or hashes.
- Thinks CSP runs on the server.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.