Security Header Scanner

Find out which security headers a live URL actually serves, how strong the values are, and what is missing.

Secure server processingSecurity & PrivacyWorkingNo account needed

What this tool does

Security Header Scanner asks the OmniKitly processing service to request the address you give it and reports what arrived above the body: the URL the request ended on, the HTTP status, a score such as 5/9, a table of every graded header with the value it carried, and a findings list. The full set grades nine — Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the three Cross-Origin policies — and adds a cookie table showing Secure, HttpOnly and SameSite for each cookie set. The core five drop everything after Referrer-Policy. The JSON behind the report, including every header the site returned and not only the graded ones, downloads alongside it.

Two headers are judged on more than a name: X-Content-Type-Options has to read exactly nosniff to count, and framing passes on either an X-Frame-Options header or a frame-ancestors directive inside the CSP. The rest count the moment they appear, but the findings then read the values. A Strict-Transport-Security max-age under 15552000 seconds is called out, as is one with no includeSubDomains; a CSP that allows unsafe-inline or unsafe-eval, or that sets neither default-src nor script-src, is named; a Referrer-Policy of unsafe-url is flagged; and a Server or X-Powered-By header carrying a version number is reported as something an attacker reads first. The score stays a coverage count, and the findings are where the judgement lives.

The three controls each change the run. Request as decides the user agent the service sends — a desktop browser, a mobile browser, or a plain scanner identifying itself as OmniKitly — which matters because a CDN, WAF or bot rule can answer each of them differently, and a header set that changes with the caller is a real misconfiguration. Follow redirects, when on, follows up to five hops with every hop re-checked before it is called and grades whatever answers at the end; turned off, the redirect itself is graded, and the report says so and names the destination rather than letting a 0/9 read as a failing site. Header set chooses between the full nine and the core five, and it narrows what is graded, scored and reported, not just what is printed.

Where the work happens decides what you can point it at. The address travels to the processing service over an encrypted connection, the request leaves that machine rather than your browser, and the job record and the JSON it produced are deleted together once the short retention window passes. Nothing of your session goes with the request — no cookie, token or credential — so a URL behind a login answers with its sign-in redirect or a 401, and those are the headers you get graded. The scanner also only reaches the public web: each hostname is resolved before a connection is opened and every address it returns is checked, so an internal host is refused whether you name it by a private IP, by localhost, or by a public name that quietly points at one.

How to use it

  1. Give it one exact URL. Include the scheme — https://example.com/account rather than a bare domain — because header rules are usually attached to a route or a hostname rather than to a whole site.
  2. Choose which client to arrive as. Desktop is the default. Run the same URL again as a plain scanner when you suspect a CDN or bot rule is answering automated traffic differently; a difference between the two runs is itself the finding.
  3. Decide whether to follow redirects. Leave it on to grade the page a visitor ends up at. Turn it off when the redirect is the thing you are checking — an HTTP-to-HTTPS hop that should be carrying HSTS, for instance.
  4. Pick the header set. The core five are the ones most audits cite. The full nine add Permissions-Policy, the Cross-Origin trio and cookie flags, which is the set to use before claiming a site is thoroughly covered.
  5. Read the score, then the findings. The score counts headers that are present. The findings underneath say what is missing, which values are too weak to help, and which cookies were set without Secure, HttpOnly or SameSite.

Processing & privacy

Secure server processing. This operation requires temporary server processing.

Common use cases

Proving a header survived the edge

A policy set in the application can be stripped by a proxy or CDN on the way out. The scan reads the response as the public internet receives it, not as the configuration file describes it.

Working through an audit finding

Penetration-test reports list missing headers by name. Rescanning the exact URL the report cited says whether the fix reached production or stopped at staging.

Catching an HSTS max-age that is too short to matter

A max-age of a few hundred seconds passes any presence check and protects almost nobody. The findings name the number, convert it to days, and give the 15552000 figure that preload lists expect.

Seeing whether the edge answers bots differently

Running the same URL as a desktop browser and again as a plain scanner shows whether a CDN or WAF is serving a challenge page, a different cache state or a flat 403 to automated traffic.

Checking the route nobody configured

Header rules often land on the marketing site and miss the app, the API subdomain or the file host. Each address is a separate scan and frequently a separate answer.

Sizing up a site you do not run

Any public address can be scanned without access to it, which makes this a quick way to see how a supplier, a competitor or a host you are evaluating sets its headers.

Questions

Is the URL sent to a server?
Yes. Cross-origin rules stop a browser page from reading another site's response headers, so the address goes to the OmniKitly processing service over an encrypted connection, the request is issued from there, and the job record and its JSON are removed when the short retention window expires.
Does a full score mean the site is secure?
No. It means the graded headers were present. The findings do read the values — a short HSTS max-age or a CSP allowing unsafe-inline is named — but none of this looks at the certificate, the software behind the site, or anything in the page itself. Treat a full score as a floor rather than a finding.
Do the Request as and Header set controls change the scan?
Yes. Request as changes the user agent the service sends, so a site that varies its headers by client shows the difference between two runs. Header set changes which headers are graded and scored: the core five, or the full nine plus cookie flags.
Are cookie flags checked?
Yes, on the full header set. Every cookie the response sets is listed with its Secure, HttpOnly and SameSite state, and any missing flag is raised as a finding. The core five leave cookies out, matching what that option says it covers.
Can it scan a page that needs a login?
No. The request carries none of your cookies or tokens, so a protected URL replies with a redirect to the sign-in page or a 401, and the headers reported belong to that reply rather than to the page you wanted.
Why does the result differ from what my browser shows?
The scan arrives from a data centre with no history. A CDN, WAF or bot rule may answer it with a challenge page, a different cache state or a flat 403, and the headers on that reply are the ones graded. Changing Request as is the quickest way to test whether that is what is happening.
How does this differ from HTTP Header Inspector?
Both make the same request of the service. This page is built around the security score, the value findings and the cookie flags, while HTTP Header Inspector renders every header as a formatted listing whether or not it relates to security. For certificates and expiry dates use SSL Certificate Checker instead — nothing here inspects TLS.

Related tools

  • Protect PDF — Add a password and set permissions on a PDF.
  • Sign PDF — Draw, type or upload a signature and place it on the page.
  • Hash Generator — Compute MD5, SHA-1, SHA-256 and SHA-512 digests.
  • Password Generator — Generate strong passwords with rules you control.
  • Redact PDF — Permanently remove sensitive content, not just cover it.
  • Remove PDF Metadata — Strip identifying metadata before you share a file.