Security headers explained: which ones your site needs

The short answer: the five headers that matter most are Strict-Transport-Security (always use HTTPS), Content-Security-Policy (which scripts and other resources may load, and who may frame your pages), X-Content-Type-Options: nosniff, Referrer-Policy and Permissions-Policy (switch off browser features you don't use). X-Frame-Options is still worth sending for older browsers, and Cross-Origin-Opener-Policy is a useful extra. Old headers such as X-XSS-Protection, Expect-CT and Public-Key-Pins are no longer needed, and some can cause harm.

Security headers are instructions your server sends with each page, telling the browser to switch on protections. This guide explains what each one does, sensible starting values, and how to add them without breaking your site.

Why security headers matter

Headers don't fix weaknesses in your website's code. They add a second layer: if an attacker finds a way to inject a script, or tries to load your site inside their own page, the browser can block it. They cost nothing to send and are supported by every modern browser.

The OWASP Secure Headers Project keeps an up-to-date list of recommended headers and values. The sections below follow its advice.

The headers most sites need

Strict-Transport-Security (HSTS)

Tells the browser to use HTTPS for your site for a set time, even if someone types http:// or clicks an old link. This stops attackers on public Wi-Fi from downgrading the connection.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Browsers only accept this header on an HTTPS response. max-age is in seconds; a year is common. Add includeSubDomains only when every subdomain works over HTTPS. The MDN HSTS reference explains the options.

Content-Security-Policy (CSP)

The most powerful header, and the hardest to get right. It lists where scripts, styles, images, fonts and frames may load from. If an attacker injects a script from somewhere else, the browser refuses to run it.

A strict starting point for a simple site that loads everything from itself:

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; form-action 'self'

Real sites usually need more: analytics, fonts, maps, payment forms or advertising all load from other domains. See the MDN CSP reference for every directive.

X-Content-Type-Options

Stops browsers guessing a file's type from its contents. Without it, a file uploaded as an image could be treated as a script.

X-Content-Type-Options: nosniff

This is the only valid value, and it's safe for almost every site. See MDN.

Framing: frame-ancestors or X-Frame-Options

Stops other sites loading yours in a hidden frame and tricking visitors into clicking things (clickjacking). The modern way is the frame-ancestors directive in your CSP. The older header still works and is worth sending too, for older browsers:

X-Frame-Options: SAMEORIGIN

Use DENY if your pages are never shown in a frame, even by your own site. If you do need to allow a partner site to embed a page, list it in frame-ancestors; X-Frame-Options can't name other sites in modern browsers.

Referrer-Policy

Controls how much of the current address is shared with other sites when a visitor follows a link. Full addresses can contain private information, such as search terms or reset tokens.

Referrer-Policy: strict-origin-when-cross-origin

This sends only your domain name to other sites, and nothing when going from HTTPS to HTTP. It's the default in modern browsers, but sending it makes your intent clear. See MDN.

Useful extras

Permissions-Policy

Switches off browser features your site doesn't use, such as the camera, microphone or location, so injected code can't use them either.

Permissions-Policy: camera=(), microphone=(), geolocation=()

It's optional and doesn't protect you by itself, but it narrows what an attacker can do. See MDN.

Cross-Origin-Opener-Policy

Separates your page from pages it opens or that open it, which protects against some cross-site attacks.

Cross-Origin-Opener-Policy: same-origin

Test it if your site uses pop-up sign-in or payment windows, as those may need same-origin-allow-popups instead.

Headers you can remove

How to add security headers

Where you add headers depends on your hosting:

• Apache or LiteSpeed shared hosting: add Header always set lines to your .htaccess file, if your host allows it.
• Nginx: use add_header … always; in the server block.
• Content delivery networks: most let you add response headers in their dashboard.
• Website platforms and applications: many have a setting or plugin, or the application sends them itself.

For example, in .htaccess:

Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Frame-Options "SAMEORIGIN"

Testing after a change

1. Run the Security Header Checker on your home page and on one or two other important pages, such as the sign-in or checkout page.
2. Open the site in a browser with the developer tools open, and look for CSP errors in the console.
3. Test the things most likely to break: forms, payments, embedded videos, maps, analytics and adverts.
4. Check that the headers are on every response, including error pages and redirects. The HTTP Header Checker shows the full set of headers for any address.

Common questions

Do I need these headers on a simple brochure site?

The cheap ones, yes: HSTS, nosniff, a referrer policy and a framing rule cost nothing and rarely break anything. A content security policy takes more care, but even a basic one with frame-ancestors and object-src 'none' is worth having.

Should headers be on every page?

Yes. Browsers apply headers to each response separately, so a header on the home page doesn't protect other pages. Set them at the server or CDN level, so they're added everywhere, including error pages.

Can a header break my site?

A content security policy can, if it blocks something the site needs. HSTS can lock visitors out if HTTPS stops working. That's why both are best introduced carefully: report-only mode for CSP, and a short max-age for HSTS to begin with.

Why does the checker look at the final page?

Because that's the page the browser shows. If your site redirects from http:// to https://, or from the bare domain to www, headers on the redirect itself don't protect the page. The checker tells you which address it ended up on.

Checklist

• HSTS on HTTPS responses, starting with a short max-age.
• A CSP, tested in report-only mode first, including frame-ancestors.
• X-Content-Type-Options: nosniff.
• X-Frame-Options for older browsers.
• Referrer-Policy: strict-origin-when-cross-origin or stricter.
• Deprecated headers removed.