The small security headers everyone skips: nosniff, Referrer-Policy, Permissions-Policy

HSTS and CSP get the attention because they're the big ones. Sitting just below them is a set of smaller headers that almost every site forgets, each a single line, each closing a specific gap. None of them will be the reason you get breached on their own. All of them together are the difference between a hardened response and a sloppy one, and they cost about thirty seconds to add.

Here are the four worth knowing, what each one actually does, and why their absence shows up on a scan.

X-Content-Type-Options: stop the browser guessing

When a browser isn't sure what a file is, some browsers historically tried to guess by sniffing the content. That sounds helpful and is occasionally dangerous: an attacker uploads a file your server labels as text/plain, the browser sniffs it, decides it looks like JavaScript, and runs it. MIME sniffing turns a benign-looking upload into executable code.

X-Content-Type-Options: nosniff turns the guessing off. The browser trusts the Content-Type you declared and won't reinterpret a text file as a script. It's the most clear-cut of the four: there's essentially no downside, and its absence is a small but real foothold, especially on any site that serves user-uploaded files.

Referrer-Policy: stop leaking your URLs

Every time a visitor clicks a link off your site, the browser by default tells the destination where they came from, including the full URL. If your URLs carry anything sensitive in them, a password-reset token, a session id, an internal path, a query that reveals what the user was doing, that detail gets handed to whatever third party they clicked through to, and to every analytics script on the page.

Referrer-Policy controls how much of that leaks. The weak settings (unsafe-url, no-referrer-when-downgrade) send the full URL; a sane setting like strict-origin-when-cross-origin sends only your domain to other sites and the full URL only to your own. The scanner flags both the missing header and the weak values, because a token in a URL is exactly the kind of thing that ends up in someone else's logs.

Permissions-Policy and the legacy X-XSS-Protection

Permissions-Policy lets you declare which browser features your site is allowed to use: camera, microphone, geolocation, and so on. Setting it to deny what you don't need means that if an attacker ever does inject content into your page, they can't trigger a camera or location prompt through it. It's defense in depth, narrowing what injected code can ask for.

The fourth is a cleanup, not an addition. X-XSS-Protection is a legacy header from old browsers, and its filter is buggy enough that the value 1 could itself be abused; modern guidance is to set it to 0 or rely on CSP instead. The scanner flags the old 1 value, because turning a deprecated, exploitable filter back on is worse than leaving it off.

# response headers, the small ones absent
HTTP/1.1 200 OK
Content-Type: text/html
# no X-Content-Type-Options
# no Referrer-Policy
# no Permissions-Policy
# X-XSS-Protection: 1   (legacy, buggy)

Why a scan reports them at all

Individually these are low-severity, and we grade them that way. They appear on the report for the same reason a good code reviewer flags small things: not because any one of them is urgent, but because their absence is a reliable signal that nobody set the response headers deliberately. A site missing all four is almost always a site where the headers were never configured, which means the big ones, HSTS and CSP, are often missing too. The small headers are the canary for the whole header posture. Fixing them is the same edit where you'd fix a missing HSTS header or a weak CSP, because they all live in the same place: one server config block or one middleware function that stamps every response.

Set them once at the server or framework level so every route gets them, rather than per-page, and they're done forever.

Which of these headers your responses carry is readable by anyone who sends a request and looks at what comes back, so it's checkable from outside in a single round trip. SurfaceCheckr reads your response headers and reports which of these are missing or set to a weak or legacy value, alongside the higher-severity header findings, so you get the whole header posture in one pass rather than four separate tools. These won't move your grade much by themselves, and we won't pretend they're critical. What they tell you, and us, is whether anyone has actually looked at the headers you serve, and adding the four-line block is the cheapest hardening on the list.