What a single page already knows about a visitor
Address, network, browser, fonts, timezone. See the profile your own site could build without asking.
What We Know About You →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.
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.
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.
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.
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.
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.
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.
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.
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.