What a content security policy does for your website

Your security scan says “Content-Security-Policy header missing”. It sounds serious, and the name does not explain itself. Is your website unsafe? What would it even do?

Short answer: a content security policy, or CSP, is a rulebook your website hands to every visitor’s browser. It lists what the page is allowed to load and run. If an attacker manages to sneak in bad code, the browser can refuse to run it. It is a useful second layer, not a cure for a hacked site. This guide explains it in plain English.

What a content security policy is

Mozilla’s developer documentation describes CSP as a series of instructions from a website to a browser, which place restrictions on the things that the code making up the site is allowed to do. Your site sends it as a header, a short note that travels with every page.

A typical rule reads like a guest list: “scripts may only come from my own site and from my analytics provider. Images may come from my site. Nothing else is invited.” Anything not on the list is blocked by the browser before it runs.

The problem it is built for

Many website attacks work by getting the attacker’s code onto your page. The usual name is cross-site scripting. An attacker finds a weak spot, such as a form field or an out-of-date plugin, and injects a small piece of script. When your customer opens the page, that script runs as if you had written it. It can steal what they type, change what they see or send them elsewhere.

MDN says the main use of CSP is to control which resources, in particular JavaScript, a page is allowed to load, and that this is mostly a defence against this kind of attack. If the injected script is not on the guest list, the browser does not run it.

What else it can do

• Stop your pages being shown inside someone else’s. One CSP setting controls which sites may put your page in a frame. This helps against clickjacking, where a visitor is tricked into clicking something hidden on top of your page.
• Push everything to https. Another setting tells the browser to upgrade plain http requests for your page’s resources to https. See our guide on what HSTS is for the related protection on the connection itself.
• Warn you before it blocks. A CSP can be set to “report only” mode. The browser does not block anything, but it reports what would have been blocked.

The honest limits

A CSP is not a shield you switch on and forget.

• It is a second layer. The OWASP cheat sheet calls a strong CSP an effective second layer of protection, especially against XSS, and says it should not be relied on as the only defence. The first layer is still updates, careful code and strong logins. If your site is already hacked, read what to do if your WordPress site is hacked.
• A weak policy gives a false sense of safety. A policy that allows everything to run inline protects very little. OWASP’s advice is to move inline code into separate files so the policy can stay strict.
• It can break your own site. If the guest list forgets your chat widget, your payment form or your analytics, the browser blocks them and visitors see a broken page.

Why third-party scripts matter

Most business sites load code from other companies: analytics, chat, fonts, booking tools. OWASP points out that if one of those outside sites is compromised, the attacker’s code can reach your visitors through you. A CSP that names exactly which outside sources are allowed limits the damage. It also makes you list what your site depends on, which is useful on its own.

How to roll it out safely

The safe order, as MDN and OWASP both describe it:

1. List everything the site loads and from where.
2. Start in report-only mode, so nothing is blocked while you learn what would break.
3. Fix or allow the legitimate items, and remove things you no longer use.
4. Only then switch to enforcing the policy, and keep watching the reports.

So, does your website need it?

Our view, which you can weigh against your own situation:

• Yes, if your site takes logins, orders, payments or personal details. There is more to steal, so the second layer is worth having.
• Worth doing, but not urgent, for a simple brochure site. Get updates, backups and logins in order first.
• Not before you know what your site loads. A policy written without that list will either be too weak to help or too strict to work.

What to ask your host or developer

1. Does our site send a content security policy today? Is it enforced or report only?
2. Which outside companies’ code do our pages load, and do we still use all of them?
3. Does the policy allow inline code to run, and if so, why?
4. Who reads the violation reports, and how often?
5. If we tighten it, how do we test before visitors are affected?

Vague answers are useful information in themselves.

Want us to check yours?

Start with the free website security checker. It looks at your site from the outside, the way a stranger would, and tells you in plain English whether the security headers browsers look for are in place. If it shows a gap and you would like it closed safely and in the right order, see our website security service.

• Email hello@wpfoss.com
• WhatsApp +254 118 271 160
• Tell us what you need

Sources and further reading

• Content Security Policy (CSP), MDN Web Docs. Source for what CSP is, the XSS and clickjacking uses, the https upgrade setting and report-only mode.
• Content Security Policy Cheat Sheet, OWASP. Source for CSP as a second layer, moving inline code out, staged rollout and the risk of compromised third-party scripts.