Overview
Content Security Policy (CSP) is a powerful response header that tells the browser which content sources a page may load and execute. It is a key defense-in-depth control, especially against XSS. This lesson covers CSP in the context of security headers.
Learning objectives
- Explain what CSP controls.
- Describe key directives and a strong policy shape.
- Understand CSP's role and limits.
Core concept
CSP (Content-Security-Policy header) restricts the sources from which a page may load resources (scripts, styles, images, frames) and whether inline scripts may run. Key directives include default-src (fallback policy), script-src (allowed script sources), style-src, img-src, connect-src, and framing controls via frame-ancestors. A strong policy limits scripts to trusted sources and disallows arbitrary inline script, using nonces or hashes to permit specific legitimate inline scripts.
How it works
The browser enforces the policy the server sends: it refuses to load resources from disallowed sources and, under a strict policy, blocks inline scripts lacking a valid nonce/hash. So even if an XSS flaw injects script, the browser won't execute it if it violates the CSP — containing the impact. CSP does not fix the underlying flaw; it limits what injected content can do. Its effectiveness depends on avoiding weakening options like unsafe-inline or wildcard sources, which would let injected/inline script run and negate the benefit.
Practical example
A site sends Content-Security-Policy: default-src 'self'; script-src 'self' (and uses nonces for any needed inline script). If a stored-XSS payload injects an inline <script>, the browser blocks it for violating the policy — the attack fails to execute despite the flaw. Had the policy included unsafe-inline, the injected script would run, defeating the purpose. A strict, well-designed CSP thus provides real protection; a permissive one provides little.
Cybersecurity relevance
CSP is a widely recommended defense-in-depth control that can neutralize the impact of XSS and mitigate some data-exfiltration and injection vectors. Common findings are a missing CSP or a weak one (unsafe-inline, wildcards). It is not a replacement for output encoding (which prevents the flaw); rather, it is a second layer that contains flaws that slip through. Defenders deploy a strict CSP alongside proper encoding; testers assess whether a CSP is present and genuinely restrictive.
Common mistakes
- Omitting CSP entirely, or deploying a weak policy (
unsafe-inline, wildcard sources). - Treating CSP as a replacement for output encoding rather than a complementary layer.
- Not using nonces/hashes for legitimate inline scripts, then loosening the policy.
Key takeaways
- CSP restricts which sources a page may load/execute and whether inline scripts run, enforced by the browser.
- A strong policy limits scripts to trusted sources and disallows arbitrary inline script (using nonces/hashes); it contains XSS impact even when a flaw exists.
- CSP is defense in depth, not a replacement for output encoding; weak policies (
unsafe-inline, wildcards) provide little protection.
Check your understanding
- How can CSP prevent injected script from executing even when an XSS flaw is present?
- What common CSP weaknesses make the policy largely ineffective?