What we check
The scan reads the response headers of the scanned URL after the last redirect. Three things count: Strict-Transport-Security, a protection against framing (X-Frame-Options or a CSP with frame-ancestors), and a Content-Security-Policy. All three set means "ok". If one is missing, the line names what is there and what is not, and reads "to review". If all are missing, also "to review", marked as a weak baseline.
What the scan does not rate: the content of the headers. A CSP with default-src * counts as set, so does an HSTS with a one-second lifetime. Further headers such as Referrer-Policy, Permissions-Policy or X-Content-Type-Options stay out of scope, as do subpages and static assets that a CDN may serve with different headers.
Why it matters
The CSP is the header where tracking and IT meet. It decides which scripts run, and every new tag endpoint has to be in it: the tag manager, the server-side container on your own subdomain, the CMP, the pixels after that. One missing entry and the browser blocks silently, the data flow stops, and in reporting that looks like a campaign problem. We have been there ourselves: for weeks the live configuration of datascale.de lacked data: in script-src while the repository carried the right policy. The difference was visible only in the response, nowhere in the code.
HSTS makes sure the browser never requests the page over HTTP again after the first visit. Frame protection stops someone from loading your page inside a foreign frame and harvesting clicks. Both are baseline, not a project.
Common causes
- The host serves default headers; nobody ever configured a security policy.
- A CSP existed, but after frontend errors it was removed entirely instead of repaired.
- A proxy or CDN overwrites the headers set by the backend on delivery, or sets them only for dynamic pages, not for statically cached ones.
- The headers live in the application, but the static pages come straight from the web server or the edge and do not carry them.