Home / Knowledge hub / Content Security Policy
Knowledge hub
Content Security Policy
A header telling the browser which scripts a page may load.
What it means
A Content Security Policy is a header that tells the browser which scripts and styles a page may load, and where they may come from. The browser itself refuses anything outside that list.
It is a second line of defence rather than a first. It does not fix the bug that let a script in. It limits what that script can do once it is there.
Why it matters
Set well, it turns many cross-site scripting bugs from a breach into a blocked request. That is a large change in outcome for a change that touches no application code. Set badly, it does almost nothing while looking reassuring in a report, which is the more common situation.
Teams that treat it as the main defence tend to relax it whenever a new tool needs to run a script. After a year of small exceptions it protects very little.
Browsers also report what a policy blocks, and almost nobody reads those reports. A collection endpoint you never look at is a policy you are not really running.
How it shows up
The permissive policies are the ones that fail. A policy allowing inline scripts, or allowing anything at all from a large public content network, leaves an attacker room to work in. A policy is only as strong as its loosest entry.
Nonces and hashes are the way out of inline scripts. They take real work, which is why so many policies keep the loose setting and stop protecting anything.
Roll it out in report only mode first, watch what it would have blocked for a fortnight, then enforce. Starting with enforcement is how a checkout page breaks on a Friday.
Questions people ask
Content Security Policy, answered
How does a Content Security Policy actually work?
Your server sends a header listing what the page may load and where it may come from. The browser reads that list and refuses anything else.
Enforcement happens in the browser, which is why an attacker who injects script into your page cannot switch it off.
Why is my own script being refused by the policy?
Because the policy does not cover where it came from. The usual culprits are an inline script tag, a third party somebody added last week, or a build tool that generates code at runtime.
Read the browser console message. It names the directive that blocked the load, which is almost always enough to fix it.
What is the point of a policy that still allows inline scripts?
Very little, for the attack it is meant to stop. Injected script usually arrives inline, so allowing inline lets it run.
You keep some value against remote code from unexpected places. But a policy with that setting should not be described as protection against scripting flaws. OWASP points at nonces or hashes as the way out.
What is the difference between CORS and CSP?
They point in opposite directions. CORS decides which other sites may read responses from your server. A content security policy decides what your own page may load and run.
One is about other people reading your data. The other is about what executes on your page.
Our policy broke a third-party font. Do we just loosen it?
Add the specific origins that the font loading needs rather than opening the directive. Fonts usually need a style source and a font source, and naming both keeps the rest closed.
The habit matters more than the single case. Every broad exception added in a hurry is one nobody takes back out.
Related
Terms that sit next to this one
XSS
An attacker's script running in your pages, in your customers' sessions.
Nonce
A value issued for a single use, so it cannot be replayed later.
Clickjacking
Tricking someone into clicking your button while it is hidden from them.
Input validation
Checking that what arrives is the shape and range you expected.
Is your policy blocking anything?
A loose policy looks reassuring and blocks very little. We test what actually runs on your pages and report the scripting flaws it would not have stopped. Ask us to look at one application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.