HTTP Security Headers: What They Do and Why Most Sites Skip Them

HTTP security headers are response headers — instructions the server sends to the browser alongside your web content — that tell the browser how it should handle and protect that content. They're not visible to users. They cost nothing to implement beyond the engineering time to configure them. And they prevent entire categories of attack that would otherwise require no attacker skill to execute.

Most websites don't have them. Not because of a technical barrier — they're server configuration, not application code — but because they're not part of the default setup for most hosting environments, and they don't appear as a visible feature once they're missing.

The headers that matter most

Content-Security-Policy (CSP). CSP tells the browser which sources are allowed to load scripts, styles, images, fonts, and other resources on your page. Without it, a cross-site scripting (XSS) attack — where an attacker injects malicious script into your page — can load scripts from anywhere and run them in the context of your domain. With CSP, the browser refuses to execute scripts from unauthorized sources, regardless of how they got there.

CSP is the most complex header to configure correctly — an overly restrictive policy breaks your own site, an overly permissive one provides minimal protection. The starting point is a reporting-only mode (Content-Security-Policy-Report-Only) that logs violations without blocking, so you can understand your site's actual resource load before enforcing the policy.

Strict-Transport-Security (HSTS). HSTS tells the browser that this site should only be accessed over HTTPS, for a specified period. Without it, a user who types your domain without https:// makes an initial HTTP request that can be intercepted and modified before the redirect to HTTPS happens. With HSTS, the browser enforces HTTPS from the first request for any domain it's seen before.

The includeSubDomains and preload directives extend this protection to subdomains and to browsers that have never visited your site before (via the HSTS preload list, a database maintained by browser vendors).

X-Frame-Options / frame-ancestors. Controls whether your site can be embedded in an iframe on another domain. Without this, clickjacking attacks — where your site is loaded in an invisible iframe and positioned over a malicious page to capture clicks intended for your interface — are straightforward to execute. Set to DENY or SAMEORIGIN unless you specifically need cross-origin embedding.

X-Content-Type-Options. A single directive: nosniff. Without it, browsers may try to infer the content type of a response rather than trusting what the server declared — which can turn a file upload containing malicious script into an executable attack vector. With it, the browser uses exactly the declared content type and nothing else.

Referrer-Policy. Controls how much of the referring URL is sent when a user navigates from your site to another. Without it, internal URLs — which may contain session parameters, user IDs, or sensitive path structures — get transmitted to external domains in the Referer header. strict-origin-when-cross-origin sends only the origin (not the full path) for cross-origin navigation.

Permissions-Policy. Restricts which browser APIs the page (and any embedded content) can access — camera, microphone, geolocation, payment APIs, and others. If your site has no legitimate need to access the device camera, this header ensures no injected third-party script can access it either.

How to check your current headers

The Security Headers checker at kief.dev scans any URL and returns a graded report of which headers are present, which are missing, and what each one does. It's free, requires no account, and takes about ten seconds. Most sites score an F on the first check — not because of complex vulnerabilities, but because the defaults aren't secure and nobody configured them intentionally.

The broader technical audit process should include a security headers check — these headers affect not just security posture but also browser behavior that can interact with analytics, performance, and content delivery in non-obvious ways.

Implementation

Security headers are configured at the web server or CDN level — nginx, Apache, Cloudflare, Vercel, Netlify — not in application code. Most platforms expose them through configuration files or dashboard settings. A working implementation for most sites takes one to two hours: checking existing headers, identifying gaps, configuring the policy, testing that the changes don't break existing functionality.

This is the category of security work that security-first engineering handles as a default, not an afterthought. The fact that most sites don't have it isn't a sign that it's optional — it's a sign that most hosting setups don't configure it automatically, and most developers don't add it unless they're specifically thinking about security hygiene.

---

Dependency scanning is a parallel layer of the same posture. Vekt scans package lockfiles across npm, PyPI, Cargo, and 19 other ecosystems against CVE and malicious package databases — catching supply chain risk before it reaches your headers conversation entirely.

Related reading

• What Happens When You Get Hacked: A Realistic Timeline
• What Your Vendors' Security Posture Actually Means for You
• Building a Security Culture When Everyone Thinks It's IT's Job
• The Problem with Generic Tech Recommendations
• If the Recommendation Came Before the Questions, It's Not Advisory

Frequently asked questions about http security headers

Will adding security headers break my website?

A misconfigured CSP policy can break sites by blocking legitimate resources. The other headers rarely cause issues. The safe approach: implement non-CSP headers first (HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), verify nothing breaks, then implement CSP in report-only mode before enforcing it. Testing in a staging environment before production is the standard precaution.

Do security headers affect SEO?

Not directly — they're not a Google ranking factor. Indirectly, HSTS contributes to the secure HTTPS signal, and a site with strong security headers is less likely to be compromised in ways that would affect rankings (malware injection, content modification, pharma hacks). Treat security headers as infrastructure hygiene, not SEO optimization.

If I'm using Cloudflare or a CDN, are headers handled automatically?

Some CDNs add basic headers by default (Cloudflare adds some), but comprehensive security header configuration is rarely automatic. Check what your CDN is setting, compare against the full header list, and configure the gaps explicitly. CDN-level header configuration is often more accessible than server-level configuration, which makes it easier to implement correctly.

How often should I review security headers?

When browser security standards evolve, some header directives change — deprecated values, new directives added, CSP syntax updates. An annual review is a reasonable baseline for stable sites. Any time you make significant changes to your site's resource loading (adding analytics, changing font providers, adding embeds), revisit the CSP policy specifically to ensure it still matches your actual resource load.