No Content-Security-Policy: What It Means and How to Fix It

What a Content-Security-Policy actually does

A Content-Security-Policy (CSP) is a response header your web server can send with every page. It tells the browser an allowlist: which origins are allowed to serve scripts, styles, images, fonts and other resources for that page. When the header is present, the browser refuses to load or run anything that is not on the list.

BadgerScan flagged this finding because your site sends no Content-Security-Policy header at all. From the outside view, we can see the header is simply missing, which means the browser falls back to its default behaviour and trusts any resource the page references, from any origin.

The header is a plain list of directives. For example, default-src 'self' tells the browser to only load resources from your own origin unless a more specific rule says otherwise (MDN, Content-Security-Policy). Each resource type, such as script-src or style-src, can then be tuned to allow the specific third parties you actually use.

Why it is worth fixing

A CSP is a safety net, not a lock on the front door. Its main job is to limit the damage if a cross-site scripting (XSS) flaw ever slips into your site, for example through a comment field, a plugin, or an ad. Without a policy, an injected script can run freely and load code from anywhere. With a sensible policy, the browser blocks scripts from origins you never approved, so many XSS attempts simply fail to execute (OWASP, Content Security Policy Cheat Sheet).

Because this is a low-severity finding, there is no rush and nothing is broken today. It is a hardening step: you are reducing how bad a future problem could be, rather than fixing an active issue. That is why it is worth doing carefully rather than quickly.

How to fix it, step by step

The safe approach is to watch before you enforce. CSP has a report-only mode that lets you see exactly what your pages load without blocking anything, so you can build an accurate policy before turning it on for real. Work through these steps in order:

• Start in report-only mode. Add a Content-Security-Policy-Report-Only header instead of the enforcing one. In this mode the browser reports what a policy would have blocked but still lets every resource load, so nothing on your site breaks.
• Begin from your own origin. Set a starting policy of default-src 'self', which allows resources only from your own domain. This is your baseline before you add any exceptions.
• Discover what your pages really load. Browse your site normally with report-only active, and watch which resources get reported as violations. Those are the legitimate third parties (fonts, analytics, a payment widget) you will need to allow.
• Add the third-party origins you need, and only those. For each real dependency, add its exact origin to the right directive, for example script-src 'self' https://www.googletagmanager.com. Keep the list as short as the site genuinely requires.
• Enforce and retest. Once report-only shows no unexpected violations, switch the header name to Content-Security-Policy to enforce it. Then click through the whole site again to confirm nothing broke. Build this policy up per site, because every site loads a different set of resources.

The one thing not to do

Do not paste in a strict policy and enforce it straight away. An over-strict CSP will block legitimate scripts and styles, and the result is usually a visibly broken page: missing fonts, dead buttons, or checkout flows that stop working. That is exactly why report-only mode comes first. It gives you the full list of what your pages load before any rule is enforced, so you enforce a policy you have already proven is complete.

After you go live, you can re-check the header with our security headers checker or by running the free scan again to confirm the Content-Security-Policy header is now present.