Skip to main contentSkip to footer

Security Header Check

Test the HTTP security headers of any page: CSP, HSTS, framing, cookies, the redirect from HTTP, script integrity and CORS. Every gap comes with the exact change, every result with a link you can share. Free, no account.

Reads the HTTP response headers of a page and explains what each security header does, which ones are missing and which ones are set too loosely to help. Also checks cookie flags, the redirect from http://, integrity hashes on third-party scripts, CORS and the TLS certificate. Enter a full URL to check a specific page.

What are HTTP security headers?

HTTP security headers are instructions a web server sends with every response. They switch on protections the browser already has: which sources may run script, whether the site may ever be loaded over plain HTTP again, and whether another site may show it inside a frame. Without them the browser falls back to permissive defaults.

The reportedIP Security Header Check requests a page the way a browser does and reads those headers together with the cookies, the redirect from http:// and the script tags of the page. It grades the result from A+ to F, and every finding names the change that fixes it.

What the check covers

Thirteen checks, ordered by what they prevent. The weight is each check’s share of the score; checks with a weight of 0 are shown but not scored.

Check What it prevents Weight
Content-Security-Policy Injected script running with the rights of the page (cross-site scripting) 25
Strict-Transport-Security (HSTS) The first request of a visit going out unencrypted, where it can be redirected 20
X-Frame-Options / frame-ancestors Clickjacking: another site loading the page in an invisible frame 15
X-Content-Type-Options The browser guessing a file type and running an upload as script 15
HTTP → HTTPS redirect Visitors who type the bare domain staying on plain HTTP 10
Cookies (Secure, HttpOnly, SameSite) Session cookies sent over plain HTTP or read by injected script 10
Subresource Integrity (SRI) A compromised CDN changing the scripts your page loads 10
Referrer-Policy Full URLs, query strings included, reaching other sites 10
Permissions-Policy Embedded code asking for camera, microphone or location 10
CORS (Access-Control-Allow-Origin) Other sites reading the page with the visitor’s login 5
Server / X-Powered-By Exact version numbers that put the site on a scanner’s list 5
COOP / COEP / CORP Shown, not scored: only needed for cross-origin isolation 0
TLS certificate Shown, not scored: issuer, expiry and protocol of the certificate 0

Background on each header: the OWASP HTTP Headers Cheat Sheet and the MDN header reference.

How the score and the grade are calculated

Each check earns between 0 and 100 points, multiplied by its weight. A missing Content-Security-Policy therefore costs five times as much as a server that names its version, which matches the damage each one allows. A check that does not apply leaves the calculation instead of scoring zero: HSTS on a page served over plain HTTP, cookie flags on a page without cookies, the redirect when nothing listens on port 80.

The grade uses the letter boundaries of Mozilla’s HTTP Observatory: A from 90 points, A- from 85, B+ from 80, B from 70, B- from 65, C+ from 60, C from 50, C- from 45, D+ from 40, D from 30, D- from 25, F below that. A+ needs at least 95 points and no broken finding. The Observatory reaches A+ through bonus points above 100 and weighs some findings differently, so the two grades can differ for the same site.

Where a checklist gets it wrong

frame-ancestors replaces X-Frame-Options

When the Content-Security-Policy sets frame-ancestors, X-Frame-Options is no longer needed. The directive is its specified successor, every current browser honours it, and it can name the sites allowed to embed the page. Two cases do not count: a policy sent only as Report-Only, which blocks nothing, and frame-ancestors inside a meta tag, which browsers ignore.

max-age=0 is worse than no HSTS

It tells the browser to forget that the site was ever HTTPS-only (RFC 6797, section 6.1.1). A checklist sees a header and ticks the box; this check marks it as broken.

HSTS over plain HTTP means nothing

Browsers must ignore the header on an unencrypted response (RFC 6797, section 8.1). The check leaves it out of the calculation instead of awarding or deducting points.

A header sent twice is not always an error

Web server and CMS often both add the same header. Identical copies are read as one value, so the check accepts them and only points out the duplicate. For HSTS only the first copy counts (RFC 6797, section 8.1): if the second carries includeSubDomains and the first does not, the weaker one applies. X-Frame-Options with both DENY and SAMEORIGIN makes browsers refuse every frame, the site’s own included.

How this tool works and its limits

The address is requested with a normal GET, not HEAD, because a fair number of servers, proxies and firewalls answer HEAD with a shorter header set. Up to three redirects are followed. The request carries an Origin header from a domain nobody would allow, so a page that grants it anyway is copying any origin it is asked about. A second request goes to http:// on the same host to see where its first redirect leads, and a TLS handshake on port 443 reads the certificate.

Of the page itself, only the first 256 KB of HTML are read, for script tags and a Content-Security-Policy in a meta tag. None of the content is stored. Cookies are reduced to their names and flags before anything is saved or shown; their values are discarded.

Results are kept for one hour. Every check gets a link of the form /security-headers/?url=example.com that shows the stored result without requesting the site again, and a stored result does not count against the daily limit. Re-check fetches a fresh result once the stored one is a minute old.

The check runs from our server, so a site that varies its headers by country, user agent or login state may answer you differently. Only one page is read: headers set by the web server usually apply everywhere, but an application can add or drop them per route, so the login or checkout page is worth checking on its own. Script tags that JavaScript inserts later are not seen. The tool cannot tell whether a policy is wide enough for the site to work, and it reports the TLS version the server chose, not whether older versions are still accepted.