The free security most sites leave switched off

Most security advice for a small SaaS company costs money: a consultant, a SIEM, a headcount you don't have yet. Response headers aren't that. They're a handful of lines in your server or CDN config, they cost nothing to turn on, and they close off entire categories of attack — clickjacking, MIME-sniffing exploits, downgrade-to-HTTP interception, script injection riding on a missing content policy. There's no procurement cycle. There's no vendor. It's a config change and a redeploy.
So the interesting question isn't whether these headers work. It's whether companies actually ship them. We pulled the answer from our own scan data rather than guessing.
What we found when we scanned 705 real companies
OrangeStealth runs a passive, external-only scan across a population of US B2B SaaS companies at YC seed stage, 5-50 employees. This aggregate was generated 2026-08-21 from N = 705 companies, is k-anonymised, and names no individual company. Here's how many had each header configured on their public-facing site:
- Permissions-Policy — 83.8% of the population (n=591)
- Referrer-Policy — 74.5% of the population (n=525)
- Content-Security-Policy — 73.5% of the population (n=518)
- X-Frame-Options — 62.6% of the population (n=441)
- X-Content-Type-Options — 58.9% of the population (n=415)
- Strict-Transport-Security (HSTS) — 14.9% of the population (n=105)
Flip those numbers around and the gap gets clearer. Even the best-covered header, Permissions-Policy, is still missing on 114 of 705 sites — better than one in six. Content-Security-Policy, the header that stops a large share of script-injection attacks cold, is absent on 187. And HSTS — the header that forces every visitor's browser onto HTTPS instead of trusting whatever the first request happened to use — is missing on 600 of the 705 companies we looked at, or 85.1%. That's not a niche gap. That's the header responsible for closing off HTTPS-downgrade and session-hijacking attacks, switched off on the large majority of small B2B SaaS sites.
A concrete example
Picture a 20-person SaaS company whose app is fully on HTTPS — the padlock shows, the cert is valid, engineering considers TLS "done." But the server never sends Strict-Transport-Security. A visitor types the bare domain into their browser, or clicks an old link that still points to http://. The browser makes that first request in plain HTTP before it ever gets redirected — and that first request is exactly where an attacker on the same coffee-shop Wi-Fi or a compromised router can intercept it, strip the redirect, and quietly downgrade the whole session. One missing response header is the difference between "TLS is on" and "TLS is actually enforced." The fix is one line:
Strict-Transport-Security: max-age=31536000; includeSubDomains
No new infrastructure, no new vendor — just a header most teams assumed was already implied by "we have HTTPS."
What to actually do about it
- Check what your site actually sends. Load your homepage in a browser, open dev tools, and look at the response headers, or run it through a free tool like securityheaders.com — most founders have never actually looked.
- Add HSTS first. It's the single biggest gap in our data (85.1% missing) and it's usually one line in your CDN, load balancer, or web server config.
- Add a baseline Content-Security-Policy even if it's permissive at first (
default-src 'self'plus the third-party domains you actually use). A loose policy you can tighten beats no policy. - Set X-Frame-Options (or the frame-ancestors directive in your CSP) so your login and billing pages can't be framed by an attacker's clickjacking page.
- Re-check after every CDN or hosting change. These headers live at the edge, and a migration to a new host or proxy silently drops them more often than teams expect.
If you want to know exactly which of these your own site is missing — not a sample of 705 companies, yours specifically — that's what our External Security Posture Assessment checks, passively and from the outside, in about the time it takes to read this post.