Skip to content
Akrita
Akrita
← All posts

Why security headers matter

2 min read
  • security
  • web
  • http

When we run a web application assessment, HTTP response headers are one of the first things we look at — not because missing headers are the worst finding, but because they tell us how much the team thinks about defense in depth. The best part: they cost almost nothing to fix.

Here is what the important ones actually do.

Content-Security-Policy (CSP)

CSP is your last line of defense against cross-site scripting. Even if an attacker manages to inject markup into your page, a strict policy stops the browser from executing it. Start with default-src 'self', allowlist only what you truly need, and avoid unsafe-inline — it disables most of the protection you came for.

Strict-Transport-Security (HSTS)

HSTS tells browsers to never talk to your site over plain HTTP again. This closes the window where a first request over HTTP can be intercepted and downgraded. A typical production value:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Only add preload when you are certain every subdomain serves HTTPS — it is effectively permanent.

X-Content-Type-Options

One value, one job: nosniff stops browsers from guessing content types. Without it, a file you serve as harmless text can be reinterpreted as something executable.

Frame protection

X-Frame-Options: DENY (or the modern CSP frame-ancestors 'none') prevents your site from being embedded in someone else’s iframe — which is the whole mechanic behind clickjacking.

Referrer-Policy and Permissions-Policy

Referrer-Policy: strict-origin-when-cross-origin keeps full URLs — which may contain tokens or personal data — from leaking to third parties. Permissions-Policy lets you switch off browser features you never use (camera, microphone, geolocation), shrinking the impact of any script that does slip through.

How to check where you stand

Run your domain through securityheaders.com or simply:

curl -I https://example.com

Read the response like an attacker would: what is the browser allowed to do that it doesn’t need to?

Security headers won’t fix a vulnerable application — but they turn many “game over” bugs into contained incidents. If you’d like a second pair of eyes on your configuration, get in touch.