Compliance Audit
PUBLIC / REFERENCEEngine
SECURITY HEADERS / RULE REFERENCE

Content-Security-Policy

CSP occupies a special place in assessments: not a regulation, but the first evidence artifact a perimeter check produces. It declares which origins may load scripts, styles, frames, and connections — turning "we do not allow injected code" from a claim into an enforced policy. With XSS still a dominant vulnerability class, a missing or permissive CSP reads to an assessor as "XSS defense here is aspirational".

The rule

CSP is not a regulation, but it is the header regulators and assessors look for as evidence of XSS defense-in-depth — and the first thing a perimeter scan checks.

What it means for how you build

Declare allowed script/style/connect sources explicitly. A permissive or missing CSP means injected markup can phone home freely.

Self-check

  • Does script-src actually restrict origins — or is the policy "default-src *" theatre?
  • Are unsafe-inline / unsafe-eval still present where a nonce or hash could replace them?
  • Does it set frame-ancestors (clickjacking) and base-uri (base-tag injection)?
  • Is there a reporting endpoint — and does anyone read the reports?

Common pitfalls

  • Report-only forever: a Content-Security-Policy-Report-Only header enforces nothing.
  • Allowlisting a CDN that hosts user content — effectively allowlisting the internet.
  • CSP in a meta tag cannot restrict frame-ancestors — it must be a response header.

How the engine checks it

Perimeter header checks — shield headers and CSP posture are verified from the edge, no code access needed.

Last reviewed 2026-11-01.

Reading up on Content-Security-Policy? The engine verifies this surface from the perimeter — live on sovereign EU/UK partitions.