HTTP Security Headers Explained: How to Check and Grade Yours

Some of the most effective web security you can deploy is also some of the cheapest: a handful of HTTP response headers that tell the browser to behave more defensively. They cost a few lines of server configuration and close well-understood, common attack vectors — yet a large share of sites still ship without them. This guide explains what security headers are, walks through the ones that matter, and shows how to check and grade yours.

For the user-facing flip side of this — judging whether someone else's site is safe — see is this website safe?

What security headers are

When a server responds to a browser, it sends not just the page but a set of headers — metadata about the response. Security headers are the subset of those that instruct the browser to enforce protective behaviours. They work because the browser, not your server, is where many attacks play out: a header that says "only load scripts from these origins" or "never connect to me over plain HTTP again" hands the browser a rule it will enforce on every subsequent interaction. That makes headers a uniquely efficient defence — you set them once on the server, and the browser does the enforcement for every visitor.

The headers that matter

A handful of headers deliver most of the protection. Here is what each does and why it matters.

Strict-Transport-Security (HSTS) forces the browser to use HTTPS for your domain, even if a user types http:// or follows an old link. This defeats protocol-downgrade and man-in-the-middle attacks that rely on an initial insecure request. A typical value enforces HTTPS for a long period and can include subdomains.

Content-Security-Policy (CSP) is the most powerful header. It tells the browser exactly which sources of scripts, styles, images, fonts and other resources are permitted to load. Because cross-site scripting (XSS) works by injecting unauthorised scripts, a good CSP is the single strongest defence against it — an injected script from an unapproved origin simply will not run.

X-Content-Type-Options: nosniff stops the browser from trying to guess ("sniff") a resource's content type, which can otherwise be tricked into executing a file as script. It is a one-line header with no downside and should always be set.

X-Frame-Options (and the modern CSP frame-ancestors directive) prevents your pages from being embedded in a frame on another site, which defeats clickjacking — where an attacker overlays your page invisibly to trick users into clicking things they did not intend.

Referrer-Policy controls how much referrer information the browser sends when users navigate away, limiting leakage of potentially sensitive URLs to third parties.

Permissions-Policy lets you switch off browser features your site does not need — camera, microphone, geolocation and so on — reducing the attack surface and the risk of abuse by injected or third-party code.

Cross-Origin headers (COOP, COEP, CORP) provide isolation between your site and others, hardening against a class of cross-origin attacks and enabling certain powerful browser features safely.

A note on legacy headers

Some headers you may see in older guides are now deprecated or replaced. X-XSS-Protection is effectively obsolete — modern browsers removed the auditor it controlled, and a strong CSP is the real defence now. Public-Key-Pins (HPKP) was abandoned because it was dangerous to operate. Knowing what not to add is part of getting headers right; chasing deprecated headers wastes effort and can even cause harm.

How to check your headers

Checking takes seconds. In the browser, open DevTools → Network, reload, click the main document request, and read the Response Headers section. From a terminal, curl -I https://example.com prints the response headers directly. For a graded assessment, online tools and broader site audits fetch your headers and score them, usually on an A+ to F scale, and list exactly which are present, which are missing, and how to fix them. StackOptic, for example, grades security headers as part of a wider report that also covers performance, SEO and AI-readiness, so you see the security picture alongside everything else.

How headers are graded

Grading tools typically award points for the presence and correct configuration of the key headers, weighting the high-impact ones (HSTS, CSP, nosniff, frame protection) most heavily, and deducting for missing or misconfigured ones. An A+ generally means HTTPS is strictly enforced, a meaningful CSP is in place, and the supporting headers are all set sensibly. A poor grade usually means CSP is absent (the most common gap, because it is the hardest to deploy) and several one-line headers are simply missing. The grade is a useful shorthand, but read the detail — a high grade with a permissive, near-useless CSP is worse than it looks.

How to add them (carefully)

Most headers are added in your web server or application configuration (or at a CDN/edge), and the one-liners — nosniff, frame protection, Referrer-Policy, HSTS — can usually be deployed immediately with little risk. CSP is the exception and deserves caution. A strict policy can accidentally block legitimate scripts, styles or third-party tools and break your site. The safe path is to deploy CSP first in Content-Security-Policy-Report-Only mode, which reports violations without enforcing them; watch the reports, refine the policy until only genuine threats would be blocked, and only then switch to enforcing mode. Rolling out HSTS also warrants care: start with a shorter max-age, confirm everything works over HTTPS including subdomains, then increase it.

How a missing header is actually exploited

It helps to see why these matter concretely. Without HSTS, an attacker on the same network can intercept a user's first http:// request and downgrade the connection, reading or altering traffic before HTTPS ever takes hold. Without a Content-Security-Policy, an injected <script> — slipped in through a vulnerable input, a compromised third-party tag, or a malicious ad — runs with full access to the page, able to steal session tokens or harvest form data; a good CSP would refuse to execute it because its origin is not on the allow-list. Without X-Frame-Options, an attacker can load your real page invisibly inside their own and trick users into clicking buttons they cannot see (clickjacking). Without nosniff, a file uploaded as an image but crafted to look like script can be executed by a browser that guesses wrong. Each header, in other words, closes a specific, well-documented attack — they are not abstract best practices but direct countermeasures to things attackers actively do.

A recommended baseline

For most sites, a sensible baseline looks like this: enforce HTTPS with HSTS (after confirming HTTPS works everywhere); set X-Content-Type-Options: nosniff and frame protection (via X-Frame-Options or CSP frame-ancestors) immediately, since they are safe one-liners; add a sensible Referrer-Policy (such as strict-origin-when-cross-origin) and a Permissions-Policy that switches off features you do not use; and work toward a meaningful Content-Security-Policy, starting in report-only mode. That set closes the common attack vectors without much risk, and it is achievable for almost any site in an afternoon plus a CSP rollout period. The one-liners give you most of the grade immediately; CSP earns the rest over a careful deployment.

Headers are one layer, not the whole defence

Finally, keep headers in perspective. They are a high-value layer of defence, but they do not replace the fundamentals: keeping software patched, validating and sanitising input, using HTTPS everywhere, and following least-privilege access. A site with perfect headers and an unpatched, vulnerable application is still at risk; headers harden the browser's behaviour, but they cannot fix an insecure server. Treat them as one important, cheap layer in a defence-in-depth approach — the layer that happens to be easiest to add and quickest to verify, which is exactly why it is a good place to start rather than the place to stop. A useful rule of thumb: if a security check can be done by reading a response header, an attacker can read it too, so assume they know exactly which protections you are missing and prioritise closing those gaps accordingly.

Common mistakes

• Skipping CSP entirely because it is hard — it is also the most valuable, so deploy it in report-only mode rather than not at all.
• Enforcing a strict CSP without testing, then breaking the site and rolling everything back.
• Setting HSTS with a long max-age before HTTPS is solid, which can lock users out if something is misconfigured.
• Adding deprecated headers (X-XSS-Protection, HPKP) and assuming they help.
• Checking once and forgetting — a config change or new CDN can silently drop headers, so re-check after any infrastructure change.
• A high grade with a token CSP — a permissive policy that allows almost everything looks good to a grader but provides little real protection.

Go deeper

• Judge other sites: is this website safe?
• Protect your email too: SPF, DKIM and DMARC explained.
• The broader stack: how to find out what a website is built with.

Want your security headers graded A+ to F with specific fixes? Analyse any site with StackOptic — security, performance, SEO and AI-readiness in one report, free.