Read the HTTP security headers a site actually sends, and find out which ones are missing, weak, or quietly cancelling each other out. Free, no account.
Security Header Check
HTTP security headers are instructions a web server sends with every response to switch on protections the browser already has: which sources may execute script, whether the site may be loaded over plain HTTP, and whether another site may frame it. The reportedIP Security Header Check reads those headers, weighs each one by what it actually prevents, and names the concrete change for every gap.
How this tool works and its limits
The address is fetched with a normal GET request, following up to three redirects, and the response headers are read. GET rather than HEAD, because a fair number of servers, reverse proxies and firewalls answer HEAD from a different code path with a shorter header set, which would report headers as missing that a real browser does receive. The check is run from this server, so a site that varies its headers by country, by user agent or by login state may answer differently to you.
The score is weighted, not a count. Content-Security-Policy and Strict-Transport-Security carry the most weight because they decide whether injected script runs and whether a request can be forced back to plain HTTP. Referrer-Policy and Permissions-Policy limit leakage and weigh less. COOP, COEP and CORP carry no weight at all: they exist to isolate pages that need high-resolution timers, and a site that does not need them is not less secure for leaving them out.
X-Frame-Options is not reported as missing when the Content-Security-Policy sets frame-ancestors. frame-ancestors is the specified successor, every current browser honours it, and it can name individual permitted origins, which X-Frame-Options never could. A Content-Security-Policy sent only in Report-Only form is treated as what it is: a measuring instrument that records violations and blocks nothing.
Only one page is read. Headers are usually set at the server or proxy level and therefore apply everywhere, but an application can add or drop them per route, so checking the page that matters, the login or the checkout, is worth more than checking the front page. The tool reads headers only and never inspects the page content, so it cannot tell whether a policy is actually wide enough for the site to work.
Why a header list is not a score
Most header checkers hand you a checklist and a grade. That treats a missing Permissions-Policy as the same size of problem as a missing Content-Security-Policy, which it is not. One of them narrows what a browser API may do; the other is the difference between a cross-site script running and not running.
This check weighs each header by what it prevents. Content-Security-Policy counts most, then HSTS, then framing protection and content type sniffing. Cross-origin isolation headers are reported but scored at zero, because a site that never needed them should not lose points for that.
Where a checklist gets it wrong
frame-ancestors replaces X-Frame-Options. A site with a proper Content-Security-Policy does not need the older header, and demanding both is advice from ten years ago. A report-only policy does not count, because browsers do not enforce it.
max-age=0 is worse than no HSTS. It actively tells the browser to forget that the site was ever HTTPS-only. A checklist sees a present header and ticks the box.
HSTS over plain HTTP means nothing. Browsers ignore it there, so the check leaves it out of the calculation instead of docking points for it.
What it reads
The page is fetched with a normal GET request, not HEAD, because some servers answer the two differently and the headers a browser sees are the ones that matter. Only the response headers are inspected; the page content is not stored.