Security headers checker

What this checker looks at

Every web response starts with headers, and a handful of them are instructions to the browser about safety. They decide whether an injected script may run, whether the page can be tucked invisibly inside another site, whether the connection must stay on HTTPS and how much of the address leaks when someone clicks a link. None of them show on the page, so the only way to know they are there is to look. This tool fetches the page from LookupOwl's server, follows any redirects to the page a visitor would land on, and grades the headers of that final response.

Nine headers are scored: Content-Security-Policy, Strict-Transport-Security, frame protection (X-Frame-Options or the CSP frame-ancestors directive), X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the three cross-origin headers (Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy). Beyond the grade, you also get a warning list for leaked server versions, deprecated headers that can do harm and headers sent twice with different values, plus a cookie audit that sits outside the score.

For each header the result says what it is, why it matters, what your response does and the exact line to send. The Content-Security-Policy gets its own tab, where every directive is read and every gap is explained in plain words.

How to use it

1. Enter the addressType https://example.com/ or just example.com. A bare host is tried over HTTPS first and over plain HTTP only if HTTPS cannot be reached. Pick the page that matters: a home page and an API endpoint often send different headers.
2. Choose a snippet formatUnder More options, pick where you will add the fixes: a plain header line, nginx, Apache, Caddy, Cloudflare Transform Rules, Vercel, Netlify, Next.js or Express. The grade does not change, only the wording of the copy-paste snippets.
3. Work from the topFixes appear in the Headers tab, biggest gaps first. Start with the ones worth the most points, add them in your staging setup, then run the check again to see the grade move.

# The same check from a terminal, as JSON
curl "https://lookupowl.com/api/v1/tools/security-headers?url=https://example.com&platform=nginx"

How the grade is worked out

The rules are fixed and public, so the same response always gets the same grade. They are our own, loosely in the spirit of other header graders but not copied from any of them, and they say nothing about whether a site is safe overall. Each of the nine headers has a weight, and the weights add up to 100. A header is rated good (all of its weight), ok (60 percent), weak (25 percent) or missing (nothing).

Points are then taken off, up to 20 in all, for three points per header sent twice with conflicting values (a conflicting X-Frame-Options already lowers its own rating instead), five for a Public-Key-Pins header or for Access-Control-Allow-Origin: * combined with credentials, two for a server version shown in Server or X-Powered-By, and one or two for an X-XSS-Protection header that switches on the retired browser filter. A response served over plain HTTP cannot score above 59. The score becomes a grade: 97 and above is A+ (and only if nothing was taken off), 90 is A, 75 is B, 60 is C, 40 is D and anything lower is F.

The three cross-origin headers are worth little on purpose. They are opt-in, and the embedder policy in particular can break a page that loads images or widgets from other sites. A site with the six classic headers done well scores 90, which is an A, and the last few points are the reward for going all the way.

Fixing what it finds

These are sensible starting values, not a copy-and-forget recipe. Each snippet in the result is the same header written for your platform.

When a header shows up twice

A common surprise is a header that appears two times, often with different values. It happens when the web server adds a header in its configuration and the application or a hosting panel adds it again, so the browser receives both. For X-Frame-Options the browsers do not agree on what a repeated or conflicting header means, and some ignore it, which silently removes the protection. The result lists every repeated header with each value it carried. The cure is to decide which layer owns the header, keep it there and remove it from the others.

What it cannot see

• One anonymous request. The check carries no login, no stored session and no custom headers, so it grades what a first-time visitor gets. A page behind a login, or one that serves different headers to different paths, needs its own check.
• Headers only. The page body is never read. A policy set in a <meta> tag, Subresource Integrity attributes and mixed content inside the page are all invisible here.
• A policy is judged, not tested. The Content-Security-Policy is read directive by directive against known weak patterns. We do not load your page to see what the policy blocks, so a good grade is not proof that nothing is exposed.
• CORS only as sent. A plain request carries no Origin, so we see the CORS headers a site sends by default and not how it answers a hostile origin.
• Cookies sit outside the score. They are listed with their flags (names and attributes, never values) so you can review them, but a missing flag does not change the grade.

The request comes from our server, which looks up the host once, checks that every address is public and connects to that exact address. Fresh checks of any one domain are limited across all callers, and results are kept for five minutes. For the full response, timing and caching details, use the HTTP headers checker; for the certificate behind HTTPS, use the SSL checker.