What is a Content Security Policy and does your website need one?
A Content Security Policy header tells browsers exactly what your website is allowed to load, closing off a class of attacks that most small business sites have no protection against.
Here's a scenario that plays out often enough to be a pattern, not a one-off: a business adds a live chat widget to their website by pasting a script tag into the page header, exactly as the instructions say to do. Six months later, the company behind that widget is compromised, and the script it's serving is quietly modified to capture whatever visitors type into forms on any site running it. Payment details, contact information, login credentials. The business whose website is affected never touched their own code. They just loaded a script from somewhere else, and their site had nothing in place to limit what that script was allowed to do.
A Content Security Policy is the control that addresses exactly this. It's a security header that tells a browser precisely which sources of content, scripts, stylesheets, images, fonts, are permitted to load on your page, and blocks everything else.
What a Content Security Policy actually does
A CSP is delivered as an HTTP response header from your web server. It contains a set of directives that define, resource type by resource type, which origins are allowed to provide that content. A basic CSP might say: scripts can only load from my own domain and from this specific third-party analytics provider. Anything else gets blocked before it executes.
Without a CSP, a browser loading your page will run any script that appears on it, regardless of where that script came from or whether it was supposed to be there. Cross-site scripting attacks, where malicious code is injected into a page either through a vulnerability in your site or through a compromised third-party dependency, rely on exactly this permissiveness. A well-configured CSP either blocks the injected script entirely or limits what it can do even if it does execute.
Why most small business sites don't have one
CSP is one of the more complex security headers to configure correctly. Unlike HSTS, which is essentially a single on/off setting, a CSP requires you to enumerate every legitimate source of content your site loads. A site pulling in Google Fonts, an analytics tag, a payment widget, a chat tool, and a cookie consent manager needs a CSP policy that explicitly allows each of those, or the policy will break things by blocking them.
That complexity means CSP often gets skipped entirely in favour of simpler wins, or a placeholder policy gets added that's so permissive it provides almost no protection. A CSP containing unsafe-inline or unsafe-eval as blanket permissions effectively undoes most of what the header is trying to achieve, since those directives allow exactly the kind of inline script execution that CSP is designed to prevent.
What a good CSP looks like in practice
For most small business websites, the goal is a policy that's tight enough to be genuinely protective without being so strict it breaks legitimate content. Building one starts with an audit of everything your site loads from external sources, then constructing the policy to allow exactly that list and nothing else.
Many developers use a report-only mode first, where the CSP header is set to observe and log violations rather than block them, letting you see what a fully-enforced policy would block before committing to it. This is the same approach as DMARC's p=none, useful for understanding your baseline before tightening.
Olimpio flags a missing CSP header as part of the CE2 Secure Configuration findings in your scan, since it's one of the security headers that Cyber Essentials assessors look for as evidence of a properly configured web environment.
Frequently asked questions
Will adding a CSP break my website? A poorly configured CSP can block legitimate content and break parts of your site, which is why starting in report-only mode and auditing what gets flagged before enforcing is the recommended approach.
Does a CSP replace other security measures like input validation? No. CSP is a defence-in-depth measure, meaning it adds a layer of protection rather than replacing other controls. Input validation and output encoding remain important regardless of whether a CSP is in place.
Can I add a CSP through my website builder or CMS, or does it need server access? Some platforms allow headers to be set through their own settings or through plugins; others require server-level configuration. A CDN like Cloudflare can add headers at that layer if direct server access isn't available.
Is a CSP worth the complexity for a simple brochure website? A basic CSP on a simple site is less complex than on a site with many third-party integrations, and even a minimal policy that restricts script sources to your own domain and explicitly approved third parties provides meaningful protection.
How does a CSP relate to other security headers like HSTS or X-Frame-Options? Each header addresses a different attack category. HSTS enforces HTTPS connections. X-Frame-Options prevents your site from being embedded in a frame on another domain. CSP controls what content can load and execute on the page itself. All three address distinct risks and are expected to coexist.
Run a free scan of your domain to see whether a Content Security Policy is present and how it fits into the full picture of your site's security configuration: olimpio.io/free-scan