How to Check Security Headers of a Website

To check a website's security headers, request the page over HTTPS and read six response headers: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options (or CSP frame-ancestors), X-Content-Type-Options, Referrer-Policy and Permissions-Policy, plus the flags on every Set-Cookie. A missing header isn't automatically a hole, and a present one isn't automatically safe: what matters is the value. Our free HTTP headers lookup shows every header a URL returns in a few seconds, with no account needed.

Every tool result below was produced live on November 3, 2026 against real sites (GitHub, BBC and example.com). The rules come from MDN, the HSTS preload list's own submission requirements and RFC 6797, all checked the same day.

Have a URL in mind? Paste the full address, including https://, into the free HTTP headers lookup and keep the result open while you read the checklist below.

The six headers that matter, and what a good value looks like

One header you can stop worrying about: X-XSS-Protection. MDN now warns that it can create XSS vulnerabilities in otherwise safe sites and recommends a Content-Security-Policy instead. That's why GitHub sends x-xss-protection: 0, which switches the old filter off on purpose.

How to check security headers step by step

1. Use the exact URL people land on

Type the full address with the scheme: https://github.com/, not github.com. When we pasted the bare domain into our tool it returned This field is required, you must fill it. instead of a result, because the scheme is how it knows what to request. Check the homepage, but also the pages that handle logins, forms or payments; they often come from a different app with different headers.

2. Run the lookup

Open the HTTP headers lookup, paste the URL and press the button. The request is made from our server, so you see what any visitor gets, without your browser's extensions or cache in the way. The tool is free and needs no account; guests get 5 lookups a day, and a free account (no spam) lifts that limit.

3. Find the hop you care about

The lookup follows redirects and lists the headers of every hop in one table. The first row shows the status line of the first response only. When we checked http://github.com, the table opened with HTTP/1.1 301 Moved Permanently, then Location: https://github.com/, and everything after that came from the final HTTPS page. So the rule is simple: the headers below the last Location row belong to the page people actually see. If you want a clean table, look up the final HTTPS address directly, and use the URL redirect checker to see each hop's status code.

4. Compare each header with the checklist

Go down the six rows of the table above. Note what's missing, then read the values of what's there, because a weak value is a more common problem than a missing header.

5. Read the cookie flags

Every Set-Cookie line the page sends appears in a single row. A session cookie should carry Secure, HttpOnly and a SameSite value. An analytics cookie may skip HttpOnly on purpose, since scripts need to read it.

Worked example 1: GitHub, the strong baseline

Our lookup of https://github.com/ returned HTTP/2 200 and these security rows (CSP shortened):

strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'; base-uri 'self'; child-src github.githubassets.com ...

What to learn from it:

• The CSP starts from default-src 'none', so nothing loads unless a directive allows it. That's the strictest starting point and the one to copy for new sites.
• The referrer policy is a list. MDN documents this as a fallback: the browser uses the last value it supports, so modern browsers apply strict-origin-when-cross-origin and older ones fall back to the first.
• The cookies are set correctly for their jobs. _gh_sess and logged_in carry HttpOnly; secure; SameSite=Lax. The _octo cookie has secure; SameSite=Lax but no HttpOnly, which fits a value meant to be readable by scripts.

There is no Permissions-Policy in the response. That's a reminder that even very well run sites don't send everything, so treat the checklist as a guide, not a score.

Worked example 2: BBC, present but weak values

The lookup of https://www.bbc.com/ showed:

referrer-policy: no-referrer-when-downgrade
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=31536000; preload

A quick scan says four out of six. A careful read finds two real issues:

• The referrer policy is weaker than the browser default. MDN states that browsers use strict-origin-when-cross-origin when no policy is set, and that no-referrer-when-downgrade was the previous default. Setting the old value explicitly makes the browser send the full page URL, path and query to every other HTTPS site, where saying nothing would send only the origin.
• The HSTS header asks for preloading but can't qualify. The preload list at hstspreload.org requires includeSubDomains along with preload and a max-age of at least one year, sent on the base domain. We checked https://bbc.com/ too: it returns a 301 to the www host with the same max-age=31536000; preload, no includeSubDomains.

There's no Content-Security-Policy in the response either. On a page that loads ads and many third-party scripts, that is the biggest gap, and also the hardest to close.

Worked example 3: example.com, nothing at all

https://example.com/ returned HTTP/2 200 with date, content type, server: cloudflare, cache rows and no security headers. Requested over plain http:// from our server, it answered HTTP/1.1 200 OK with no redirect to HTTPS. On a real site that would be the first thing to fix. On a static documentation page with no logins, cookies or forms, the risk is small. That's the context rule: a missing CSP on a brochure page and a missing CSP on a checkout page are not the same finding.

Pitfalls that make a check misleading

• HSTS on the HTTP redirect doesn't count. MDN and RFC 6797 say browsers ignore Strict-Transport-Security received over plain HTTP. GitHub's http:// hop sends only the 301 and Location; the header arrives with the HTTPS page, which is correct.
• A 302 from HTTP to HTTPS works, but a 301 is cleaner. http://www.bbc.com/ answered 302 Found while http://github.com/ answered 301. Both reach HTTPS; HSTS is what removes that first insecure request on later visits. Our guide to checking 301 and 302 redirects explains the difference.
• Content-Security-Policy-Report-Only enforces nothing. It only reports. Seeing it means the site is testing a policy, not protected by one.
• A CDN can add or strip headers. If the origin server sets a header but the lookup doesn't show it, check your CDN rules before blaming the app.
• A meta tag isn't a header. A CSP set with <meta http-equiv> won't show in a headers lookup and doesn't support frame-ancestors. Use the meta tags checker to see what's in the HTML.
• Headers don't prove a site is trustworthy. A phishing page can send a perfect set. To judge a site you don't know, follow our guide to checking if a website is legit and look at the certificate with the SSL lookup.

A sensible starting set for your own site

For a typical site served only over HTTPS, this is a safe first version. Test it on a staging copy before production, and roll the CSP out as Report-Only first:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'

Add includeSubDomains only when every subdomain works over HTTPS, and don't add preload until you're sure, since leaving the preload list is slow. Then run the free headers lookup again and confirm each line arrived exactly as written.

Frequently asked questions

How do I check security headers for free?

Paste the full URL, including https://, into the free My Botsy HTTP headers lookup. It lists every response header in seconds with no account. You can also run curl -sI followed by the URL in a terminal, or open your browser's developer tools, choose Network and click the page request.

Which security headers should every website have?

Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options set to nosniff, a Referrer-Policy and protection against framing through X-Frame-Options or CSP frame-ancestors. Permissions-Policy is worth adding on pages with third-party embeds. X-XSS-Protection is obsolete; set it to 0 or leave it out.

Why does the headers lookup show a 301 first?

The lookup follows redirects and lists every hop in one table, and its first row shows the first response's status. The headers after the last Location row belong to the final page. Look up the final HTTPS URL directly for a clean result.

Is a site without a Content-Security-Policy unsafe?

Not automatically. CSP limits the damage if someone manages to inject a script. A static page with no logins, forms or third-party scripts has little to protect, while a login or checkout page without CSP has a real gap.

Can I add security headers without access to the server?

Often yes. CDNs such as Cloudflare can add response headers through their rules, and many hosts let you set them in .htaccess or the control panel. CSP can also go in a meta tag, but frame-ancestors only works as a real header.

Do security headers help SEO?

Their job is protecting visitors, not rankings, so don't add them expecting a traffic jump. What they do help with is trust and consistency: HSTS keeps returning visitors on HTTPS, and a clean HTTP to HTTPS redirect means search engines see one version of every page.