Website security headers, explained, and how to grade yours

Security headers are one of the highest-return, lowest-effort things you can do for a website. They are a handful of instructions your server sends with every page that tell the browser to behave more defensively, and most sites are missing several of them. Here is what the main ones do, how they get graded, and how to check where your site stands.

What a security header actually is

When someone visits your site, your server responds with the page and a set of HTTP response headers, metadata the browser reads before it renders anything. A few of those headers are security instructions. They do not change how your site looks. They change what the browser will and will not allow, which closes off a set of common attacks before they can start. You add them once in your server or CDN configuration, and they apply to every visitor.

The headers that matter most

• Strict-Transport-Security (HSTS). Tells the browser to only ever connect to your site over HTTPS, even if someone types "http" or clicks an old link. It shuts the door on a class of downgrade and interception attacks.
• Content-Security-Policy (CSP). The most powerful and the most involved. It tells the browser exactly which sources of scripts, styles, and other content are allowed to load, so an injected script from somewhere else simply does not run. It is the strongest single defense against cross-site scripting, and also the one that takes the most care to configure without breaking your own page.
• X-Content-Type-Options. A one-value header ("nosniff") that stops the browser from second-guessing file types, a trick attackers use to make a harmless-looking file execute as code.
• X-Frame-Options / frame-ancestors. Controls whether other sites can load yours inside a frame, which is how clickjacking works. Set it so only you can frame your own pages.
• Referrer-Policy. Limits how much of your URL is passed along when a visitor clicks away, so you are not leaking private paths or query strings to third parties.
• Permissions-Policy. Lets you switch off browser features your site does not use, such as the camera, microphone, or geolocation, so a compromised script cannot reach for them.

How security headers are graded

Because the set of recommended headers is well established, your configuration can be scored against it on a letter scale, A+ down to F, the same way regardless of who runs the check. The grade reflects which headers are present, whether their values are set safely, and whether any weaken your posture. It is a clean, comparable signal: a site at F is missing the basics, an A has them configured and tuned. You can check your grade against the standard yourself, and you should be able to reproduce it.

How to check yours

Two layers are worth checking together, because they travel as a pair:

• The headers themselves, graded against the recognized standard, so you know which are missing and which need tightening.
• Your TLS and certificate configuration, the encryption underneath, which is graded on its own A-to-F scale.

A scan checks both. Run a scan and the report grades your security headers and your TLS setup and tells you which specific headers to add or fix, in plain terms. Our methodology page covers exactly how each is evaluated.

Headers are one layer, not a complete security program. A strong grade closes off a real and common set of browser-based attacks, and it is a signal that a site is looked after, but it does not by itself make a site secure. It is a high-value foundation, and most sites are leaving it on the table.

Where to start

Check your grade first. Adding the missing headers is usually a small, well-understood configuration change your developer or host can make quickly, and it is one of the few security improvements that costs almost nothing and applies to every page at once.

FAQ

Are security headers hard to add?

Usually not. Most are a single line in your server or CDN configuration. Content-Security-Policy is the exception; it takes some care to configure so it blocks injected content without blocking your own scripts, so it is worth testing before you enforce it.

Will security headers slow down my site?

No. They are a few bytes of metadata sent with each response and have no meaningful performance cost.

Do security headers make my site secure?

They close a specific, common set of browser-based attacks and are a strong foundation, but they are one layer. Real security also depends on your software, your server, and your practices.