What is a content security policy?

A Content Security Policy (CSP) is a security header that tells the browser which sources it is allowed to load scripts, styles and images from - and refuses everything else, which blocks most cross-site scripting and content-injection attacks. It is the most powerful header you can set, and also the easiest to misconfigure: a policy that is too strict will quietly break your own site before it ever stops an attacker. For a small business, that combination - high value, high fiddliness - is exactly why it belongs near the end of the security-header job, not the start.

What a CSP actually does

Every other security header does one small, fixed thing. A CSP is different: it is an allowlist. You hand the browser a list of the sources you trust - your own domain, your analytics provider, the font service you use, the payment widget - and the browser treats anything not on that list as hostile and declines to load it.

The attack it is built to stop is cross-site scripting: a stranger finds a way to inject their own JavaScript into a page you serve - through a comment field, a search box, a vulnerable plugin - and that script then runs in your visitors' browsers with all the trust your site has earned. It can steal session cookies, rewrite the page, harvest what people type into a form. A CSP shuts most of this down at the source, because the injected script comes from somewhere that is not on your allowlist, so the browser never runs it. The same allowlist also catches injected images and stylesheets, and it can forbid your page from being framed by another site - which is the overlap with X-Frame-Options and the clickjacking defence.

The reason it matters more than the other headers is breadth. A single well-built CSP covers a category of attack that no other header touches, and it does it for every visitor, on every page, with no software to install. The MDN Content Security Policy reference is the canonical write-up of every directive if you want the full vocabulary.

Why it's the hardest header to get right

Here is the trap. The other security headers your site needs are essentially set-and-forget - you add the line, nothing breaks, you move on. A CSP is the opposite. Because it is an allowlist, it only works if the list is complete, and modern websites load from more places than anyone remembers.

Think about what a typical small-business site actually pulls in: Google Fonts, an analytics tag, a chat widget, an embedded map, a booking calendar, a payment script, maybe a tracking pixel from an ad campaign someone ran last year. Every one of those is a source the browser has to be told to trust. Miss one, and the browser does exactly what you told it to - it blocks that resource. The result is a site that looks broken in ways that are maddening to diagnose: the contact form silently fails, the map is a grey box, the fonts fall back to Times New Roman, and none of it shows an error a normal visitor would report.

That is why a CSP punishes the set-it-and-pray approach that works fine for the other headers. The fix is not to be braver - it is to use the safety mechanism the standard was built with, which lets you watch what a policy would break before it breaks anything.

Do small businesses need one?

High value, but not first. 79% of Australian small-business websites publish no Content Security Policy, and the median site scores grade F on Red Bridge Cyber's Security category^* - so on the raw numbers, a working CSP would put you ahead of nearly everyone. But that grade-F median is mostly the easy headers being absent too, and those are where the return is highest for the least risk.

The honest priority order is the one in the website security checklist: get HTTPS clean and forced first, then add the simple headers - Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, a Referrer-Policy. Those are the ones you can set in an afternoon with no chance of breaking your own site, and they close most of the gap on their own. If you want the shortlist of which ones to set and why, what security headers should my site have lays them out, and what a security header is covers the concept from scratch.

A CSP comes after that. It is worth doing - the cross-site-scripting coverage is the strongest single thing you can add - but it is the one header where rushing costs you a broken site, so it earns its place at the back of the queue, done carefully, not bolted on in the same five minutes as the rest.

How to add one safely

There is exactly one right way to deploy a CSP for the first time, and it is built into the standard: start in report-only mode.

Instead of sending the live Content-Security-Policy header, you send Content-Security-Policy-Report-Only with the same rules. In report-only mode the browser enforces nothing - every resource still loads - but it tells you, in the browser console and optionally to a reporting endpoint, every single thing the policy would have blocked. You get a complete list of the sources your site actually depends on, including the three you forgot, without a single visitor seeing a broken page.

The sequence is:

1. Write a draft policy covering the sources you know about - your own domain, your fonts, your analytics, your payment and chat widgets.
2. Ship it as Content-Security-Policy-Report-Only and leave it for a week or two of normal traffic, including campaigns and edge cases.
3. Watch the reports. Each entry is either a legitimate source you need to add to the allowlist, or genuinely something that should not be loading. Tune until the report-only stream is quiet.
4. Only then switch the header name from Content-Security-Policy-Report-Only to Content-Security-Policy. Now it enforces - against a policy you have already proven does not break your own site.

This is the whole discipline. It turns a CSP from the riskiest header into a measured one, because you never enforce a rule you have not first watched in the wild. If you run WordPress or a hosted site builder, there is usually a plugin or platform setting that handles the header for you - but the report-only-first sequence is the same regardless of how the header gets sent. After you flip it to enforcing, re-test with a tool like securityheaders.com to confirm the live header is what you intended.

When this isn't enough

A CSP defends the browser, not the server - and that boundary is worth being clear about. It stops injected scripts from running, but it does nothing about how they got injected in the first place. If your site has a vulnerable plugin, an out-of-date CMS, or a form that does not sanitise what people type, those holes are still open; a CSP is a strong second line, not a reason to skip patching and updates. It also does nothing for the threats that never touch your website at all - a CSP will not stop a spoofed-invoice email sent from a lookalike domain, or a staff member handing over a password to a convincing phishing page.

It also will not fix the other half of the loading story. A CSP governs which sources load; it does not force them to load over HTTPS - that is what avoiding mixed content and a clean Strict-Transport-Security setup are for. The headers work as a set, which is why the checklist treats them as one job rather than a single hero header.

The ACSC Small Business Cyber Security Guide puts headers in their proper place: a real but bounded control sitting alongside backups, multi-factor authentication, updates and staff awareness. A CSP is the strongest brick in the website wall - it is not the whole house. If you would rather see where your site stands before deciding whether the CSP is even worth the effort yet, run a scan and the Security category will show which headers you are missing against the Australian small-business baseline, in the order worth fixing them.