Security headers: what each one does, and what a missing one allows

Why headers are worth a check of their own

Most security findings need an active test. Headers do not: the server publishes them with every page, so reading them is harmless and takes one request. That also makes them the easiest thing to lose. A theme update, a new CDN, a reverse proxy that strips unknown headers, or a developer who copied a config from another project can silently remove a policy that took a day to tune.

A missing header is not a vulnerability in itself. It is a missing limit on how bad an unrelated flaw can get. That is why the check reports them as findings to review, with a priority, rather than as failures.

The six headers the free check reads

Content-Security-Policy

Limits which scripts, styles, frames and connections the page may load. Without it, any script that reaches the page can run, whether it came through a comment field, a third-party widget or a compromised dependency. It is the one control that caps the damage of a cross-site scripting flaw. Start in report-only mode, read what the site legitimately loads, then enforce.

Strict-Transport-Security (HSTS)

Tells the browser to use HTTPS for this host for a set period, so a later visit cannot be downgraded to HTTP. The check treats a max-age under one year (31,536,000 seconds) as weak: it is below the browser preload threshold and leaves a window on first visits. Send it only once every subdomain you intend to cover serves HTTPS.

X-Frame-Options

Stops the page being embedded in a frame on another site, which is what clickjacking relies on: the visitor believes they are clicking your interface while acting on a page the attacker controls. Send DENY, or use a frame-ancestors directive in the Content-Security-Policy, which supersedes it.

X-Content-Type-Options

With nosniff, the browser trusts the declared content type instead of guessing. Without it, an uploaded file can be guessed as a script and run. Low effort, no side effects.

Referrer-Policy

Controls how much of the current URL is sent to the next site a visitor clicks through to. Without a policy, a URL carrying a search term, a token or a document ID can leak to third parties in the Referer header. strict-origin-when-cross-origin is the usual safe default.

Permissions-Policy

Declares which browser features the page and its embedded frames may use: camera, microphone, geolocation and others. A brochure site that uses none of them can deny them all, which also stops an embedded third-party frame from asking.

The full scan on verified domains also notes the cross-origin isolation headers (Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-Policy). They matter for sites that handle sensitive data in the browser and are often unnecessary for a marketing site; enabling them can break embedded third-party content, so they are reported for review rather than as something to fix.

Reading the result honestly

Present means the homepage response carried the header. It does not prove every page or every subdomain sends it, and a CDN can add headers at the edge that the origin never sent. Missing means the homepage response did not carry it; a redirect to another host is not followed, so check the host visitors actually land on. Weak is only reported for the unambiguous case, HSTS under a year. The check does not argue about whether a particular Content-Security-Policy is strict enough, because that needs the full page and its legitimate resources, which a one-request check cannot see.

Fixing a header is usually a one-line change in the web server, the CDN or the framework. Test the Content-Security-Policy in report-only mode first; the other five rarely break anything.

Read next

• What the free check includesCertificate expiry, headers, email policies, cookie flags and public files.
• Certificate expiryThe one finding with a deadline, read from the live handshake.
• See the client reportHow a missing header is written up with evidence and a next step.