Fix guide · tested 18 October 2026

How to fix "Content Security Policy missing"

Security scanners report "Content Security Policy (CSP) header missing" when your responses don't include a Content-Security-Policy header.

"Content Security Policy missing" means your site doesn't send a Content-Security-Policy header, so browsers will run any script that ends up on your pages, including one injected through a cross-site scripting (XSS) bug. Fix it by listing where your scripts, styles, images and connections are allowed to come from, starting from a strict base such as default-src 'self'. Roll it out with Content-Security-Policy-Report-Only first so nothing breaks, fix what it reports, then switch to the enforcing header. Check it with curl -sI https://yoursite.com | grep -i content-security.

How we tested this: This site enforces the policy shown in step 4 on every page, with a looser one only where a tool needs it. We checked the live headers with curl, and the pages in Chrome with no CSP errors, on 18 October 2026.

Why it matters

MDN's CSP guide describes a Content Security Policy as a way to control which resources a page may load, mainly to reduce the risk of cross-site scripting. Without one, if an attacker gets a script tag into your page, through a comment field, a URL parameter or a compromised third-party script, the browser runs it with full access to the page and its users' sessions.

A CSP doesn't fix the bug that let the script in, but a strict one stops most injected scripts from running. Free header scanners such as Mozilla's HTTP Observatory check for it.

Check it first (read-only)

One ordinary request. It prints your policy if you have one and changes nothing.

curl -sI https://yoursite.com/ | grep -i content-security-policy

No output means no CSP header. A <meta http-equiv="Content-Security-Policy"> tag counts too, but some directives, such as frame-ancestors, only work in the header.

The fix, step by step

List what your pages load. Open your main pages with DevTools → Network and note every external domain for scripts, styles, fonts, images and API calls (fetch or XHR), plus any inline scripts or styles.
Write a draft policy. Start strict and add only what you found. A static site with no third parties can use default-src 'self'. Add an analytics domain to script-src and connect-src only if you use it. Avoid 'unsafe-inline' and 'unsafe-eval' for scripts; move inline scripts into files instead.
Deploy it as Report-Only. Send the draft as Content-Security-Policy-Report-Only. Browsers report violations in the console without blocking anything. Browse every page type and fix or allow what it reports.
```
Content-Security-Policy-Report-Only: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
```

Enforce it. When the console is clean, switch to the enforcing header. This is the policy this site sends on most pages, set in a _headers file on Cloudflare Workers static assets.

/*
  Content-Security-Policy: default-src 'self'; img-src 'self' data:; style-src 'self'; script-src https://static.cloudflareinsights.com; connect-src 'self' https://cloudflareinsights.com; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests

Loosen it only where a page needs it. If one page needs more, such as a tool that calls an external API, give that path its own policy rather than loosening the whole site. Our Supabase exposure checker page is the only one here that allows connections to *.supabase.co. Then verify with the curl check and the browser console.

Apps built with AI tools

Single-page apps from Lovable, Bolt or v0 usually load a bundled script from your own domain and call an API such as Supabase from the browser. A workable starting point is script-src 'self' and a connect-src that lists your API's domain. Check for inline scripts the build adds, analytics tags and payment widgets, each of which needs its own entry. Report-Only mode is the safe way to find them.

Common mistakes

Adding 'unsafe-inline' to script-src to make errors go away. It lets injected inline scripts run, which defeats most of the point.
Using wildcards such as https: in script-src. Any HTTPS site could then serve scripts to your page.
Two CSP headers. If a CDN and your app both send one, browsers enforce both, and the result is stricter than either. Set it in one place.
Forgetting frame-ancestors. frame-ancestors 'none' stops other sites from framing yours, and only works in the header.

FAQ

What does "Content Security Policy missing" mean?

Your site doesn't send a Content-Security-Policy header, so browsers aren't told which sources of scripts and other resources to trust.

What is a good basic CSP?

For a site with no third-party scripts: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. Add specific domains for any analytics, fonts or APIs you use.

Will adding a CSP break my site?

It can, if the policy blocks something your pages load. Deploy it as Content-Security-Policy-Report-Only first, fix what the browser console reports, then enforce it.

Is a meta tag CSP enough?

It works for most directives, but some, such as frame-ancestors and reporting, only work in the HTTP header. Prefer the header.

How do I check my CSP without changing anything?

Run curl -sI https://yoursite.com/ | grep -i content-security-policy, or use a free header scanner such as Mozilla's HTTP Observatory.

Want someone to check it for you?

We check this as part of the $49 AI Site Audit. See how we test and what we don't check.

How this guide was made: researched and drafted with AI assistance, then every step was run and checked as described above on 18 October 2026. Editorial responsibility: ChikuOS. Found a problem? Email hello@chikuos.com.