Security
A content security policy is in place
security.missing-csp
Why this matters
A content security policy tells the browser which scripts it may run. Without one, anything that manages to get injected into a page — through a compromised plugin, a hijacked advert, or a comment field — runs with the same trust as your own code.
Who fixes it
A developer
Roughly how long
Varies
Care needed
Change carefully
How to fix it
Add a policy in report-only mode first so you can see what it would have blocked without breaking anything, then tighten it once the reports are clean. Doing it the other way round takes sites down.
On your platform
WordPress
A job for whoever runs your hosting rather than for WordPress itself. If Cloudflare sits in front of your site, add it there under Rules → Transform Rules → Modify Response Header; on Apache hosting it can go in `.htaccess`. Either way start with `Content-Security-Policy-Report-Only` and leave it a week: WordPress themes and plugins load scripts from places you will not have predicted, and going straight to the enforcing header is how a site goes blank.
Shopify
You cannot set this on Shopify. Storefront response headers are controlled by Shopify and merchants cannot add or override them — there is nothing in your admin that will change it and no app that can. A gap in the platform rather than a mistake in your shop: worth knowing, not worth your afternoon.
Drupal
Either at the web server, or with the Security Kit (`seckit`) module, which keeps the policy in Drupal's own configuration and is the easier route if you do not control the server. Whichever you pick, use its report-only mode first — Drupal sites tend to pull scripts in from several modules at once, and you want that list before you enforce anything.
Joomla
Joomla 4 and 5 ship a System – HTTP Headers plugin that sets this without touching the server. Enable it and use its content-security-policy settings in report-only mode first, so you can see what would have been blocked. If the plugin is disabled, `.htaccess` is the fallback.
How we score it
Failing this check takes up to 10 points off your security score. It is a fact about your site rather than a measurement, so it reads the same on every scan until you change something.
Does your site pass this one?
This check runs on every scan, along with the other 106. Free, no account, and you see the evidence for each result.
Check my siteOther security checks
- Browsers are told to stay on HTTPSYour site works over HTTPS, but it never tells browsers to remember that. The very first visit of the day can still be sent over an insecure connection before the redirect happens, which is the window an attacker on shared Wi-Fi needs.
- Camera, microphone and location access are restrictedAnything embedded in your pages — an advert, a chat widget, a map — can ask the visitor for access to their camera, microphone or location, and the request appears to come from you.
- Cookies are only sent over an encrypted connectionA cookie without the Secure flag is sent over a plain, unencrypted connection as readily as over an encrypted one. Anyone sharing a network with the visitor — a café, a hotel, an office guest network — can read it, and a single request to the http version of the site is enough to expose it, even when every page normally redirects to https. The flag costs nothing and there is no reason for a cookie on a secure site to be missing it.
- File types cannot be second-guessedWithout this header a browser may ignore what your server says a file is and guess instead. An uploaded image that is secretly a script can then be run as one.
- Folders are not browsableYour server is showing a file listing instead of a page. Anyone can read it and see exactly what is in that folder — backups, spreadsheets, database dumps, anything left there and forgotten.
- Login cookies are hidden from scripts on the pageA session cookie marked HttpOnly can be sent to the server but cannot be read by JavaScript running on the page. Without that flag, any script that ends up on the site — through a compromised plugin, a hijacked advert, or a comment field that did not escape its input — can read a logged-in session and use it from somewhere else. It is the difference between a script injection being an embarrassment and being an account takeover.