Missing Content-Security-Policy Header

What this finding means

Your site gives browsers no enforced allow-list restricting where scripts, styles, or other resources can load from, so if any part of the site is ever tricked into rendering attacker-supplied markup, the browser has no additional layer stopping it from executing.

Two configurations produce this finding. The header may be absent altogether, or it may be present as a policy that grants everything: a lone default-src whose sources are wholly permissive — *, or a bare scheme such as https: — with no other directive narrowing it. A browser applying that policy permits exactly what it would permit with no policy at all, so it is reported the same way and carries the same fix.

Why it matters

CSP is one of the strongest browser-side defenses against cross-site scripting (XSS) and content-injection attacks. If an attacker manages to inject a `<script>` tag or an inline event handler into a page (through a comment field, a stored-XSS bug, a compromised third-party script), a well-configured CSP stops the browser from executing it because the injected content doesn't come from — or match the rules of — an allowed source. It also restricts framing and mixed content when the right directives are set.

What Nivaronix checks

Nivaronix's security headers checker inspects the response headers your site sends and reports whether Content-Security-Policyis present and whether it restricts anything at all. This is a security misconfiguration check based on the header's presence and configuration — not a vulnerability scan, exploit attempt, or penetration test.

This check is deliberately narrow, and it is not a CSP audit. It answers one question with an unambiguous answer: is every policy in the header nothing but a default-src that allows everything? It does not grade the rest of your policy. It does not judge 'unsafe-inline' or 'unsafe-eval' inside an otherwise real policy, check whether your script-src is tight enough, look for bypassable CDN origins, or verify nonces and hashes. Any directive beyond default-src and pure reporting directives — script-src, frame-ancestors, object-src, upgrade-insecure-requests — is treated as meaningful and the policy is left alone. Under-reporting is the deliberate direction: a passing result here means your policy is not vacuous, not that it is well-built.

Evidence example

Example only, for illustration — not evidence from a live scan of any specific site.

HTTP/1.1 200 OK
(no Content-Security-Policy header present)

# reported identically — permits what no policy would permit:
Content-Security-Policy: default-src *
Content-Security-Policy: default-src https:

# not reported — another directive narrows the policy:
Content-Security-Policy: default-src *; script-src 'self'

How to fix it

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self';" always;

Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self';"

Rules → Transform Rules → Modify Response Header → set `Content-Security-Policy` to your policy string (or set it in a Worker if the value needs to vary per route).

Verify the fix

Re-run a scan on your domain, or check manually with curl -sI https://your-domain.example, and confirm Content-Security-Policy now appears in the response with the expected value.

FAQ

Standards reference

MDN — Content-Security-Policy. See the methodology page for exactly how this finding is scored.