The Security Header Almost Nobody Sets: What Content-Security-Policy Actually Does
Across the sites we scan, one finding shows up more than almost any other: no Content-Security-Policy header. It's not a critical-severity finding on its own, but it's one of the cheapest, highest-leverage security controls a website can have, and most sites simply don't bother.
What CSP actually is
Content-Security-Policy (CSP) is an HTTP response header that tells the browser which sources of content it's allowed to load and execute on your page: scripts, stylesheets, images, fonts, iframes, and more. Instead of trusting whatever HTML and JavaScript ends up on the page, the browser checks it against your policy and blocks anything that isn't explicitly allowed.
A basic policy looks like this:
Content-Security-Policy: default-src 'self'; script-src 'self' https://js.stripe.com; object-src 'none';
This tells the browser: only load resources from your own domain by default, allow scripts from Stripe specifically, and never load plugins like Flash. Anything outside that list gets silently blocked and logged to the console.
What it actually protects against
The headline use case is cross-site scripting (XSS). If an attacker manages to inject a <script> tag into your page, through a comment field, a compromised third-party library, or a vulnerable input, a strict CSP means that injected script simply won't run, because it isn't coming from an allowed source. The vulnerability might still technically exist, but CSP stops it from being exploitable.
It also limits the blast radius of compromised third-party scripts. If an ad network or analytics tag you load gets compromised (which happens more often than people assume; we cover a real example in a separate post about tag manager risks), CSP restricts what that script can connect to and load, even if it's now running malicious code.
Why most sites don't have one
Two honest reasons. First, most people don't know it exists; it's not part of any framework's defaults, and no build tool nags you about it. Second, the sites that do know about it are often scared to add it, because a misconfigured CSP can silently break your app: fonts don't load, a payment widget stops working, an embedded video disappears, and there's no obvious error beyond a browser console warning most people never check.
That fear is reasonable. A CSP written by guessing is a CSP that breaks production.
How to add one without breaking your site
- Start in report-only mode. Set
Content-Security-Policy-Report-Onlyinstead of the enforcing header. The browser will log violations to the console without actually blocking anything, so you can see what your policy would break before it does. - Audit what your page actually loads. Open DevTools → Network on every major page type (homepage, checkout, dashboard) and note every third-party domain you load scripts, fonts, styles, or iframes from.
- Write a policy that allows exactly those domains, nothing more. Resist the urge to use
'unsafe-inline'or wildcard*sources; both defeat most of the point of CSP. - Watch the report-only violations for a few days, tighten the policy, then switch to the enforcing header once violations stop.
- Re-check periodically. Every new script tag, embed, or third-party widget you add later needs a corresponding CSP update, or it'll break silently.
The quick way to check where you stand
If you want to skip the manual audit, paste your URL into Decloak's free scan. It checks for a missing CSP header alongside the other core HTTP security headers (X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options, and more) as part of Layer 1, and flags exactly what's missing in under 15 seconds.
CSP isn't a silver bullet, and it won't fix an underlying vulnerability. But it's one of the few security controls that costs nothing to run, doesn't slow anything down, and meaningfully reduces what an attacker can do if something else goes wrong. That combination is rare enough that it's worth the hour it takes to set up properly.
Decloak checks HTTP security headers, JavaScript CVEs, exposed trackers, and five other attack surfaces in one free scan. Scan your site free →