Security headers: which ones does your website need?

Every time a browser requests a page, the server sends a set of headers alongside the HTML: short lines of instructions. Some of them concern security. They determine, for instance, whether the browser may ever access the site over unencrypted HTTP again, which scripts are allowed to run, and whether other sites may embed your pages in a frame.

What makes them special is that the protection happens on the visitor's side. Even if an attacker manages to get malicious code onto your page, a properly instructed browser can refuse to execute it. Headers act as a safety net for mistakes elsewhere in the site: a forgotten input filter, an outdated plugin, an injection via a comment field.

They do not replace a secure development process. They complement it. A site without HTTPS and without headers scores low on any serious security measurement, however tidy the rest of the code is. The other way around: with a valid SSL certificate and the right headers, you lay the foundation the rest of the security pillar rests on.

Six headers together cover most of the risk. These are the ones the WebYes scan checks within the security pillar:

HSTS deserves a short note next to the table. Per the MDN documentation on Strict-Transport-Security, after the first HTTPS hit the browser remembers that your site may only be accessed over HTTPS. Without HSTS, every typed address can still start with an unencrypted request until the redirect kicks in.

The Content-Security-Policy deserves separate attention. This header defines, per resource type (scripts, styles, images, frames), which domains are allowed. A strict CSP makes cross-site scripting nearly impossible, because the browser simply refuses to run scripts from sources that are not on the list.

That same power makes CSP the header that most often breaks something. Forget the domain of your analytics script or embedded video, and that part stops working. So always start with Content-Security-Policy-Report-Only: the browser then reports violations without blocking anything, letting you tighten the policy before it actually enforces.

A practical order: inventory all external scripts and CDNs your site loads, write a report-only policy, review the reports for a week, and only then switch to an enforcing CSP. Anyone who ships a strict policy in one go usually finds out via complaints that the chat widget or the payment button has gone quiet. For directives, unsafe-inline and the WebYes checks, see the dedicated page on Content Security Policy.

Where you set headers depends on your setup: in the server configuration (Apache, nginx), at your CDN or hosting plan, or in your framework (for example next.config or response middleware). For most sites it is a few lines of configuration you add once and then leave alone, with CSP as the exception that needs maintenance whenever you add a new external service.

Checking requires no deep technical knowledge. The free WebYes scan tests your site's headers within the security pillar and shows the risk for each missing header. For the WebYes keurmerk the average across all pillars must be at least 80, and each pillar (including security) at least 60. Missing headers are one of the fastest ways to drop below that floor of 60.

Alongside WebYes, the Internet.nl test is useful for a broader look at modern internet standards, including HTTPS and related server settings. In our guide to the Internet.nl test you can read how that measurement relates to a product scan. Use WebYes for diagnosis and fix direction; use Internet.nl as an independent reference when you want to go deeper.

The most common miss is HSTS without a working HTTPS redirect, or the reverse: a redirect but no HSTS. Both belong together. Another classic: setting X-Frame-Options to DENY while you still need a preview or admin frame, without considering frame-ancestors in CSP as the modern alternative.

We also see sites that omit Permissions-Policy entirely, or lock it so tightly that legitimate features (a map with geolocation, an upload with camera) stop working. Start from what you actually use: block camera, microphone and geolocation if your site never needs them.

Finally: headers on the homepage and not on the rest of the site. A CDN or reverse proxy that only configures the root path leaves deep pages unprotected. After every change, check a few random URLs, not just the homepage. The free WebYes scan (beta) covers up to six pages; a paid full audit runs up to fifteen sitemap-led pages and shows the sample in the report.

If the security pillar drops below 60, start with HTTPS plus HSTS. Without an encrypted connection and browser-forced HTTPS, other headers are a plaster. Then X-Content-Type-Options (nosniff) and Referrer-Policy: low risk, quick wins. Frame protection (CSP frame-ancestors or X-Frame-Options) follows when you include embeds and clickjacking risk.

CSP comes last in the priority list, not because it is unimportant, but because it costs maintenance. Enable report-only first, inventory third parties, then enforce. That stops you hitting the keurmerk floor on headers while breaking checkout. Re-run the WebYes scan after every step; average ≥80 and each pillar ≥60 remain the hard bar.