What is Content Security Policy (CSP)? Complete Guide

So What Is CSP, Really?

Content Security Policy is an HTTP header that tells browsers which resources are allowed to load on your page. Scripts, styles, images, fonts, iframes — you name the resource type, CSP lets you lock it down to specific origins.

The short version: if something isn't on the allowlist, the browser blocks it. That's incredibly powerful for stopping XSS attacks, because even if an attacker manages to inject a script tag into your page, the browser refuses to run it.

What Happens Without It

Without CSP, a browser will happily load and execute anything on your page. An attacker who finds a way to inject a <script> tag — through a comment field, a URL parameter, a stored payload — gets full access. They can steal cookies, redirect users, exfiltrate form data, whatever they want.

CSP doesn't fix the injection vulnerability itself. Your input validation is still important. But it adds a hard backstop: even when something slips through, the browser won't execute untrusted code.

The Basics

You deliver CSP as an HTTP response header. The simplest possible policy looks like this:

Content-Security-Policy: default-src 'self'

That tells the browser: only load resources from my own domain. No third-party scripts, no external stylesheets, no CDN fonts. It's strict, and it'll probably break things on most real-world sites — but it's a useful starting point to understand the concept.

Directives You'll Actually Use

CSP is built around directives, each controlling a different resource type:

• default-src — the fallback. If you don't specify a directive for a resource type, this one applies.
• script-src — where JavaScript can load from. This is the big one for XSS prevention.
• style-src — controls stylesheets. Less critical for security, but still worth locking down.
• img-src — image origins. Usually the most permissive directive since images are low-risk.
• connect-src — governs fetch, XMLHttpRequest, and WebSocket connections.
• font-src — web fonts. Typically just your CDN or self.
• object-src — plugins (Flash, Java applets). Set this to 'none'. Always.
• frame-src — what can be embedded in iframes on your page.

Rolling It Out Without Breaking Everything

Here's the approach that actually works in practice: start with Content-Security-Policy-Report-Only. This header has the exact same syntax as the enforcing header, but the browser only reports violations — it doesn't block anything.

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

Deploy that, collect reports for a week or two, and you'll see exactly what your site loads. Third-party analytics, embedded widgets, CDN resources — it all shows up in the reports. Build your allowlist from real data, not guesswork.

Once the reports come back clean, swap Report-Only for the enforcing Content-Security-Policy header and you're live.