The 5 HTTP security headers you are missing

When your browser loads a website, the server sends back more than just the HTML. It also sends a set of HTTP response headers: small instructions that tell the browser how to behave. Most of these are technical plumbing that nobody notices. But five of them are security controls, and if they are absent or misconfigured, the browser has no way to protect your visitors against a whole class of attacks.

We run this check on every site in Noroshi. In our dataset of European SME websites, more than 80% fail at least three of these five headers. The good news: fixing them costs nothing and takes less than an afternoon.

What security headers actually do

Security headers are the server's way of setting ground rules for the browser. Without them, the browser falls back to its most permissive defaults: it will run any script, display the page inside any other page's frame, send cookies over HTTP and share your server type with anyone who asks. Each of those defaults has been exploited countless times.

The five headers that matter most:

1. Content-Security-Policy (CSP)

CSP tells the browser which scripts, stylesheets, fonts and other resources are allowed to load. A strict CSP blocks injected scripts dead: even if an attacker manages to insert a script tag into your HTML (through a vulnerability in your CMS or a compromised third-party library), the browser simply refuses to run it.

Without CSP, your site is vulnerable to cross-site scripting (XSS). XSS is consistently in the OWASP Top 10 most critical web application security risks and is the attack behind most checkout tampering incidents: a script injected into your payment page sends card numbers to the attacker's server while the transaction looks normal to everyone involved.

A strict starting policy for a site that loads only its own resources: Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'. If you use external fonts, analytics or a payment widget, those origins need to be listed explicitly.

2. Strict-Transport-Security (HSTS)

HSTS tells browsers to always use HTTPS for your domain, for a defined period, and to refuse any HTTP connection including redirects. Without it, an attacker on the same network (a public Wi-Fi hotspot, a compromised router) can intercept the first request and downgrade the connection to plain HTTP before the redirect happens.

The header looks like: Strict-Transport-Security: max-age=31536000; includeSubDomains. The max-age is one year, the minimum Google recommends for HSTS preload eligibility. Add preload to the directive and submit your domain to the browser preload list to protect users even on their very first visit.

3. X-Frame-Options

This header prevents your page from being embedded in an <iframe> on another site. Without it, an attacker can load your login page invisibly inside their own page and overlay fake UI elements on top of it. The user thinks they are clicking your button; they are clicking the attacker's. This is called clickjacking.

The fix is a single line: X-Frame-Options: DENY (or SAMEORIGIN if you embed your own pages). The CSP directive frame-ancestors is the modern equivalent and overrides X-Frame-Options when both are present.

4. X-Content-Type-Options

Browsers try to be helpful by guessing the type of a resource if the server does not declare it clearly. This is called MIME sniffing, and it is a security problem: an image upload that is actually a script can be executed if the browser decides it looks like JavaScript.

X-Content-Type-Options: nosniff switches off this guessing entirely. It is the easiest header on this list: one line, no configuration, no side effects.

5. Referrer-Policy

When a user clicks a link from your site to another, the browser sends a Referer header containing the URL of the page they came from. If your URLs contain sensitive data (a password reset token, a session identifier, an order reference), that data leaks to the destination site.

Referrer-Policy: strict-origin-when-cross-origin is the safe default: it sends the origin (your domain name, no path) to external sites and the full URL to your own domain. The most private option is no-referrer, but that breaks some analytics integrations.

How to check your site

The fastest way is to open your browser's developer tools (F12), load your homepage, go to the Network tab, click the first request and look at the Response Headers section. Or use Noroshi: create a free account, add your domain, and the scanner checks all five headers, scores them and explains exactly what to add and where.

Where to set them

Security headers are set on the web server, not in your CMS. Where exactly depends on your hosting setup:

Apache: in your .htaccess file or httpd.conf using Header always set directives. The mod_headers module needs to be enabled.
Nginx: in your server block using add_header directives. Place them in the server or location block that handles your site.
Caddy: in your Caddyfile using the header directive. Caddy sets X-Content-Type-Options: nosniff automatically; the others need to be added manually.
Cloudflare or another proxy: some proxies let you add response headers through their dashboard (Cloudflare: Transform Rules, Modify Response Header). This is the easiest option if you cannot touch the server configuration.
WordPress: plugins such as Wordfence, Headers Security Advanced and HSTS Preload set headers without requiring server access. This is a reasonable fallback if your hosting provider controls the server configuration.

What to expect from your score

Adding all five headers typically moves a Noroshi security score from the 40-60 range into the 70-80 range in a single session. They are not the only thing that matters (TLS configuration, DNS, open ports and exposed files all feed into the score), but they are the highest-effort-to-reward ratio fix available to most websites.

A well-configured site does not draw attention. Automated scanners probe millions of sites per day looking for missing headers, open ports and known software vulnerabilities. A site that sends the right headers is passed over faster and targeted less. That is not security through obscurity; it is making the easy wins unavailable.

The continuous monitoring angle

Headers can regress. A CMS update, a new plugin, a server migration or a configuration change by your hosting provider can silently remove a header that was in place yesterday. The Noroshi scanner checks all five headers on every scan and alerts you the moment one goes missing, so a maintenance window does not inadvertently become a security window.

Create a free account, add your domain and see your current header score within minutes. Free plan, no credit card required.

Written by David Hildering, the engineer behind Noroshi. More about Noroshi.