Content Security Policy (CSP)
A Content Security Policy is an HTTP header that tells the browser which sources of scripts, styles, images, and other content it is allowed to load, which is the strongest defence against cross-site scripting.
also: CSP · content security policy
CSP works as an allow-list. You declare, for example, that scripts may only come from your own origin and one named CDN, and the browser refuses anything else, including inline script an attacker managed to inject. That is why it is the main mitigation for cross-site scripting (XSS): even if malicious markup lands on the page, a strict policy stops it from executing.
The hard part is writing a policy that is tight without breaking the site. Blanket allowances like unsafe-inline defeat the point, so a strong policy uses nonces or hashes to permit only the specific inline scripts you ship. Roll it out in report-only mode first to collect violations, then enforce, and pair it with HSTS and the other security headers so the whole set is consistent rather than one strong header beside weak ones.
faq
Questions & answers
- What does a Content Security Policy protect against?
- Primarily cross-site scripting. By restricting which origins can supply scripts and other resources, and by blocking inline script unless it carries a valid nonce or hash, CSP stops injected code from running even when an attacker manages to insert it into the page.
- Why is my CSP not working?
- The usual causes are allowing unsafe-inline (which re-opens the hole CSP closes), forgetting to add a source your site genuinely uses (so legitimate scripts break), or shipping the header in report-only mode and never switching to enforce. Roll out in report-only, fix the violations, then enforce with nonces for inline scripts.
Want this applied to your stack, not just defined?
The free tools run the numbers; an audit tells you where the real cost and risk are. Book a call, or leave your email and I'll reach out.
Prefer proof first? See how this plays out in real case studies →