How do you read an HTTP security headers check result?

What the result is actually reporting

AdminKit’s HTTP security headers check fetches a URL and reads back its response headers, the same way a browser’s first request to a page does. The result is a checklist, not a single score: each recommended header is marked present or missing, and every present header shows the exact value the server sent. These headers all work the same general way — they’re instructions a server gives a browser about how to treat the page it’s about to render — and a browser only enforces an instruction it actually received. A header that’s missing isn’t silently “defaulted to safe”; the related protection simply doesn’t apply at all.

Content-Security-Policy (CSP): the broadest header

MDN’s CSP documentation describes CSP as a mechanism to “help detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks,” by letting a page restrict which origins scripts, styles, images and other resources may load from. A result showing CSP present is only half the picture — read the value’s directives (default-src, script-src, style-src, and so on). A policy that lists specific, trusted origins is doing real work; one set to default-src * or unsafe-inline for scripts provides little more protection than having no policy at all, because it permits exactly the kind of injected content CSP exists to block.

Strict-Transport-Security (HSTS): closing the plain-HTTP window

A present Strict-Transport-Security header tells a browser to refuse plain HTTP for the domain going forward, for as long as its max-age specifies — this check reports whether the header is sent and its max-age value, which matters because a short or absent max-age leaves a wider downgrade window open on repeat visits. See HSTS and HSTS preload explained for the full mechanism, including the “first visit” gap this header alone doesn’t close and what preload adds on top of it.

X-Content-Type-Options and the clickjacking headers

X-Content-Type-Options: nosniff is a single-value header with one job: it tells the browser not to guess (“sniff”) a response’s content type from its contents, overriding a declared Content-Type — MIME-sniffing has historically been a vector for getting a browser to execute content as a script that the server never intended to serve as one. There’s no partial credit here; the result shows it as present with the value nosniff, or missing.

X-Frame-Options and CSP’s frame-ancestors directive both control who can embed the page in an iframe, which is the mechanism behind clickjacking (tricking a user into clicking something they can’t see because it’s layered under a disguised, transparent frame). frame-ancestors is the newer, more flexible control and takes precedence in browsers that support it; a result showing one or the other present is sufficient, and both together is the typical belt-and-suspenders setup for the widest browser compatibility.

Referrer-Policy and Permissions-Policy: the quieter leaks

Referrer-Policy controls how much of the current page’s URL gets sent as the Referer header on outbound requests — including to third-party scripts and resources on the same page, not just links a visitor clicks. MDN recommends strict-origin-when-cross-origin as a sensible default, since a missing policy falls back to the browser’s own default, which can leak more of the URL (including query-string contents) to cross-origin requests than most sites intend. Permissions-Policy is the newer control for browser features themselves — camera, microphone, geolocation and similar — restricting which origins embedded in the page, such as third-party iframes, may request access to them at all.

Reading the result as a whole, not a pass/fail count

The check does not produce one combined score, and reading it that way misses the point: a site missing one header entirely can still be in better shape than one with every header “present” but set to an ineffective value, if the single missing header is a minor one and the “present” policy is permissive. Read each present header’s actual value against the OWASP Secure Headers Project’s reference table, prioritize Content-Security-Policy and Strict-Transport-Security first since they cover the broadest attack surface, and treat nosniff, a clickjacking header and a Referrer-Policy as the next tier.

Next step: check your own site

Run AdminKit’s HTTP security headers check against your own URL to see this breakdown for a live response. If the certificate behind that same site is also worth confirming, how to read a TLS/SSL certificate check result covers the companion check for transport encryption itself, which these headers assume is already in place.