The rule card with every answer: measuring Content-Security-Policy
Content-Security-Policy is the rule card a server sends along with every answer: per type — script, style, img, frame — it states which sources may load. The CSP analyzer fetches that card through our public API and reads it directive by directive: every enforced header and every report-only header separately, because report-only reports without refusing.
The tool measures what the policy allows, not what loads: inline scripts that may run because unsafe-inline stands there without a nonce or hash, wildcards that let every host in, framing standing wide open. These are measured facts from the header itself — HTTP headers shows this header stands beside the other response headers.
Start at your own site: paste your own address and read what your policy really allows. A policy that lets forms send to any host or frames admit any site is a measured shortfall — not a judgement of taste.
1. The header is the policy: enforced or report-only
A Content-Security-Policy exists only in the response header: if it stands there enforced, the browser refuses what falls outside the card; if it stands there as report-only, the browser reports what it would have refused and lets everything through. Measuring therefore starts with that distinction — the CSP analyzer reports both kinds separately and says honestly when only reporting happens and nothing is refused.
Where every enforced header is read separately, the browser holds their sum together: what both headers allow, may. A policy that is only placed by the page’s own JavaScript does not stand in the header and is not measured — we measure the headers of the final answer after the redirects.
2. Directive by directive: what actually holds
default-src is the safety line: if script-src stands on its own, it holds; if it does not stand, script-src inherits what default-src says. If a policy repeats one directive, the browser holds the last one with sources — the CSP analyzer measures every occurrence and reports the repetition. And object-src without any statement stands open per the specification: a box nobody closed stands on the map as open.
Then the card becomes readable: unsafe-inline in script sources is a door standing wide open, unless nonces or hashes stand in the same directive — those make unsafe-inline useless in modern browsers, and the tool reports that difference. unsafe-eval, data: scripts, wildcards as * or *.cdn.com and http: sources are separate measured shortfalls: the counts are facts from the header, the judgement is yours.
3. Framing: one rule, four states
frame-ancestors decides who may put this page in a frame. If the rule stands on *, every site can frame — that is a fault, not a nuance. If self or none stands, the circle is closed. If no framing rule stands at all, the page lies open for every framer and that is a warning. And if only X-Frame-Options stands, that is heritage: older, but read along — the CSP analyzer reports it as heritage and not as policy.
Where frame-ancestors self stands and X-Frame-Options on DENY, the two rules dispute each other: the modern one admits self, the older does not even that. Measuring what actually holds is the difference between a security header that promises something and one that does something — security headers and securing your website place the same headers in the larger picture.