Security Headers Analyzer
Fetches a URL and evaluates the response's security headers — CSP, HSTS, X-Frame-Options and more.
The URL you type is sent to the Nexinon server at analysis time, used only to fetch that URL (following up to 5 redirects) and read the final response's headers — nothing is stored, and the page's content (HTML) is never read, only the headers.
What security headers are
Security headers are instructions a site sends to the browser alongside the HTTP response — saying, for example, where scripts are allowed to load from, whether the page can be embedded in another site's iframe, or whether the connection should always use HTTPS. Unlike an antivirus or firewall, they don't protect the server: they protect the visitor, relying on the browser's cooperation to enforce the rule.
How this tool works
This tool fetches, from the Nexinon server, the given URL (following up to 5 redirects, if any) and reads only the final response's headers — the page's content (HTML) is never analyzed. Each tracked header gets its own badge (configured/could be better/missing) with its own explanation, instead of a single aggregate score — different headers protect against different risks, and collapsing that into one letter would hide which specific protection is missing.
Headers evaluated in this version
This version evaluates six headers: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy — today's most recommended core set. Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-Policy and the already-deprecated X-XSS-Protection were left out on purpose, candidates for a future version. Content-Security-Policy and Permissions-Policy are evaluated by presence and by their most relevant directives, without an exhaustive analysis of every individual directive.
Frequently asked questions
By product decision: each header protects against a different risk (clickjacking, XSS, MIME sniffing, downgrade to HTTP...), and any formula combining them into one letter would require arbitrarily deciding each one's weight — with no objective answer. Showing each header with its own badge and explanation is more educational and more honest about exactly what's missing.
Because the final destination is what matters: if the given URL redirects (e.g. HTTP to HTTPS, or to another domain), the response after all the hops is what a real visitor would actually get, reflecting the true security posture. The limit is 5 redirects; the final URL is always shown when it differs from the one entered.
No. Only the HTTP response's headers are read — no HTML is fetched, analyzed, or stored.
The header is present, but configured in a way that weakens the protection it should provide (e.g. a Strict-Transport-Security with a very short lifetime, or a Content-Security-Policy allowing unsafe-inline). Each badge's explanation details exactly why.
Every tool defines its own set of headers and evaluation criteria — there's no single universal standard. This tool prioritizes educational clarity and its own explanation per header, instead of an aggregate score.