What a header is, in one image
When a visitor opens your site, your server does not just return the page. It first returns a list of instructions for the browser: the content type, the language, how long to cache it, and possibly some security directions.
Picture a parcel. The page is the contents, the headers are what is written on the label: fragile, do not open, hand delivery only. A parcel with no label still arrives, but the carrier does as it pleases.
A site without security headers works perfectly. It simply lets the browser decide on its own, and the browser, by default, is permissive.
The six that count, and what each one prevents
Content-Security-Policy. The most important and the most demanding. It lists the sources allowed to load code on your page. Without it, a script injected through a comment flaw or a compromised extension runs as if it came from you, and can read what your visitors type into your forms. It needs careful tuning: set too strictly, it breaks parts of the site.
Strict-Transport-Security. It tells the browser: for this domain, never again accept an unencrypted connection, even if asked to. It closes the window during which a visitor on a public network can be redirected to a copy of your site. One header, one line, no side effects once HTTPS is in place everywhere.
X-Frame-Options. It prevents your site from being displayed inside an invisible frame on another page, a technique used to make a visitor click a button they cannot see. In practice, it protects your forms and your action buttons.
X-Content-Type-Options. One possible value, nosniff. It forbids the browser from guessing a file's type. Without it, a booby-trapped image uploaded by a visitor can be interpreted as code.
Referrer-Policy. It controls what your site tells others. Without it, a visitor leaving a customer-area page carries that page's full address, query parameters included, to the next site. It is a privacy topic as much as a security one.
Permissions-Policy. It declares which browser capabilities your site does not use: camera, microphone, geolocation, payment. Declaring that you do not need them is stronger than saying nothing.
The cookie case, often forgotten
A misconfigured cookie undoes part of the work above. Three attributes should be set as a matter of course:
- Secure: the cookie is never transmitted in the clear.
- HttpOnly: no script can read it, which protects a session even if a hostile script runs.
- SameSite: the cookie is not sent when the request comes from another site, which blocks an action triggered without the visitor's knowledge.
It is a three-word setting in the configuration, and it also applies to the cookies set by your analytics tools, a subject we cover in the article on cookies and trackers.
How to set them, depending on your hosting
The principle is the same everywhere: these headers are declared once, in the server configuration, and apply to every page. You do not touch your site's content.
- Standard shared hosting: a configuration file at the root, a few lines to add. Your host documents the procedure.
- WordPress: a security plugin sets them, or the server configuration file if you have access. Prefer the server when you can, one fewer plugin is one fewer dependency.
- Dedicated server or virtual machine: the nginx or Apache configuration, a single block.
One piece of advice on sequencing: set the five simple headers first, they have no side effects. Keep Content-Security-Policy for last, test it on one page before rolling it out, and check that nothing breaks.
What we measure, and what we refuse to measure
Our audit reads sixteen points in this category: the six headers above, the actual strength of the content security policy when one exists, your cookie attributes, the integrity of resources loaded from other domains, the security contact point, cross-origin isolation, and the presence of a web application firewall.
What we deliberately do not do: no port scans, no intrusive probes, no exploitation attempts. We measure only what any visitor or legitimate bot sees on arriving at your site. It is a matter of principle, explained in our methodology, and it is also what makes every finding verifiable by your own provider without taking our word for it.
For the rest of the projects, the website security guide gives the order of priority.