HTTP security headers: which ones matter

HTTP security headers are instructions your server sends to the browser with every page. Visitors never see them, but the browser follows them: use HTTPS only, refuse scripts from elsewhere, don't let another site display the page. Two matter more than the rest: HSTS and the Content Security Policy (CSP).

They are part of what our audit checks on a website's security, alongside the certificate and cookies.

A missing header is a protection that never switches on

A security header doesn't fix anything in your website. It asks the browser to close a door the site leaves open by default. So a missing header is not a visible error: the site works, and the protection simply never kicks in.

France's national cybersecurity agency (ANSSI) includes them in its recommendations for building a website (in French): they are defense in depth, limiting the damage when something goes wrong elsewhere in the site.

The six headers the audit records, and what each one prevents

Each one answers a specific situation. They are listed here by what their absence allows.

Strict-Transport-Security (HSTS) tells the browser to reach your site over HTTPS only, for a period you set. Without it, a visitor who types your address without "https" sends the first request unencrypted, before being redirected. It is defined in RFC 6797.
Content-Security-Policy (CSP) lists the sources a page may load scripts, styles and images from. A script injected from a source that isn't on the list doesn't run. The W3C publishes the specification.
X-Frame-Options says whether other sites may display your pages inside a frame. Without it, a third-party site can show your page under an invisible layer and get visitors to click without knowing it.
X-Content-Type-Options tells the browser to stick to the declared type of a file. Without it, the browser may guess the type, and treat a file served as text as a script.
Referrer-Policy decides how much of the page address is sent to the sites it calls or links to. Without it, the browser's default decides, and that default varies between browsers. The W3C specification lists the possible values.
Permissions-Policy declares which browser features the page, and the content it embeds, may ask for: camera, microphone, location.

The report also looks at Cross-Origin-Opener-Policy, which separates the page from other sites' windows it opens, and at whether your server announces its software and version number.

What we find on the sites we audit

40%don't send the HSTS header, which enforces HTTPS from the very first request

55%have no Content Security Policy at all

These percentages cover about 30 websites we audited between August 14, 2026 and September 24, 2026. Each one counts only the sites where the point could be checked. Many were audited because a defect showed up quickly, so these figures describe our audits, not websites in general.

What the audit looks at, and how a missing header counts

The audit reads the headers the way a browser receives them, on the pages it visits. The report shows each header in a table: present or missing, and its value when it is there.

The value matters as much as the presence. For HSTS, the report records the duration requested and whether it covers subdomains. For CSP, it tells a strict policy apart from one that allows any script written into the page, which protects very little.

Each missing header takes a fixed number of points off the pillar score, the same for every website. Two audits of the same site, on the same responses, give the same score.

What you set once, and what takes a project

Most of these headers are set once for the whole site: in the server configuration, with your host or the CDN in front of it, or through a CMS plugin. X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy fall into this group: they rarely change how pages behave.

HSTS is just as quick to set, but it is a commitment. Once told, the browser refuses to reach your site over plain HTTP for the whole duration requested. It only makes sense when HTTPS is permanent on every subdomain it covers.

CSP is a project. It means listing everything your pages load: your own scripts, but also analytics, chat, videos and payment. A policy that is too loose protects nothing, one that is too strict breaks pages. It gets built, tested, then enforced. Cookies have their own protections, covered in the guide on the Secure, HttpOnly and SameSite attributes.

What this check doesn't tell you

We read the headers your server sends on the pages we visit. A logged-in area or an admin page may send different ones, which we cannot see.

A header being present says nothing about the quality of the code. It limits the damage of a mistake; it doesn't fix it.

By Quentin Mathis, Z29K · updated September 28, 2026