Overview
Content Security Policy (CSP) is a browser security mechanism that restricts what a page is allowed to load and execute, providing a powerful defense-in-depth layer against XSS. This lesson explains CSP concepts and their role.
Learning objectives
- Define CSP and what it controls.
- Explain how CSP mitigates XSS.
- Understand CSP as a layer, not a replacement for encoding.
Core concept
CSP is a response header (Content-Security-Policy) that tells the browser which sources of content (scripts, styles, images, etc.) are permitted for a page. By restricting where scripts may come from and whether inline scripts may run, CSP can prevent injected script from executing even if an XSS flaw exists — a crucial second line of defense. Directives like default-src/script-src define allowed sources; a strong policy typically disallows arbitrary inline script (often using nonces or hashes for legitimate inline code).
How it works
The browser enforces the CSP the server sends: it will only execute scripts from allowed sources and, under a strict policy, will block inline scripts that lack a valid nonce/hash. So if an attacker injects script via an XSS flaw, the browser refuses to run it because it violates the policy — containing the impact. CSP does not fix the underlying XSS (the injection still occurs); it limits what the injected content can do. Effective CSP requires care to avoid being weakened by overly permissive sources (e.g. wildcards or unsafe-inline), which negate its benefit.
Practical example
A site sets a CSP that allows scripts only from its own origin and disallows inline script without a nonce. If a stored-XSS flaw slips through and injects an inline <script>, the browser blocks it for violating the policy — the attack fails to execute despite the flaw. However, if the site had used a permissive policy allowing unsafe-inline, the injected script would run, defeating the purpose. CSP thus rewards a strict, well-designed policy and punishes a loose one.
Cybersecurity relevance
CSP is a widely recommended defense-in-depth control against XSS (and some data-exfiltration and injection vectors). Its value is containing XSS impact when a coding flaw exists — but it is not a substitute for output encoding, which prevents the flaw in the first place. Common findings include a missing CSP or a weak one (wildcards, unsafe-inline) that provides little protection. Defenders deploy a strict CSP alongside proper encoding; testers assess whether a CSP is present and actually restrictive.
Common mistakes
- Treating CSP as a replacement for output encoding rather than an additional layer.
- Deploying a weak CSP (
unsafe-inline, wildcard sources) that offers little real protection. - Not using nonces/hashes for legitimate inline scripts, then loosening the policy to make things work.
Key takeaways
- CSP is a response header that restricts which content sources a page may load/execute, enforced by the browser.
- It mitigates XSS by blocking injected/inline script that violates the policy — containing impact even when a flaw exists.
- CSP is defense in depth, not a replacement for output encoding; a strict policy (no
unsafe-inline, no wildcards; nonces/hashes for inline) is what makes it effective.
Check your understanding
- How can CSP prevent injected script from running even when an XSS flaw is present?
- Why is CSP considered defense in depth rather than a replacement for output encoding?