HTTP Security Headers That Actually Matter (and the Ones That Don't)

Run any live site through a headers checker and it's common to see a wall of red, a dozen "missing" headers, most of them presented with equal visual weight, as if X-Powered-By and Content-Security-Policy carry the same risk. They don't. The OWASP Secure Headers Project documents dozens of response headers with security implications, but in practice only a handful actually change what an attacker can do, the rest are either legacy holdovers from browsers that no longer need them, or genuinely minor hardening with no real exploit path behind their absence.

The headers that do real work

• Content-Security-Policy, the single highest-leverage header on this list. A real CSP (not default-src *, which defeats the purpose) restricts which sources scripts, styles, and frames can load from, meaningfully reducing what a successful XSS injection can actually do even if the injection itself wasn't prevented
• Strict-Transport-Security (HSTS), tells the browser to never downgrade to plain HTTP for this domain again, closing the window where a network attacker could intercept the very first HTTP request before a redirect to HTTPS happens
• X-Frame-Options (or frame-ancestors in CSP), prevents your site from being loaded inside an invisible iframe on an attacker's page, which is the entire mechanism behind clickjacking
• X-Content-Type-Options: nosniff, stops the browser from trying to "guess" a file's type and executing it differently than the server declared, which has a real history of turning an innocuous file upload into script execution

The ones that mostly don't matter anymore

X-XSS-Protection is a legacy header controlling a browser-side XSS filter that Chrome, Firefox, and Safari have all removed, setting it does nothing in a current browser, and some older guidance's recommended value actually introduced a real vulnerability in Internet Explorer, which is exactly why current guidance is to omit it entirely rather than set it. X-Powered-By and Server version-disclosure headers are worth removing on general principle (don't hand an attacker your exact framework version for free), but removing them doesn't fix an underlying vulnerability, it just makes automated exploitation-by-known-CVE marginally slower to target.

Why the presence of a header isn't the same as it being correct

A checklist scanner confirms a header exists; it can't confirm the value is actually doing anything. Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' technically satisfies "has a CSP" while 'unsafe-inline' quietly defeats CSP's entire purpose against script-injection attacks, since it allows exactly the inline <script> tags a stored XSS payload would use. Our own security headers checker evaluates the actual directive values, not just presence, the same distinction that matters in a real assessment.

What to prioritize

1. A real, tested Content-Security-Policy with no wildcard sources and no unsafe-inline in script-src
2. Strict-Transport-Security with a meaningful max-age (six months minimum) and includeSubDomains
3. X-Frame-Options: DENY or the equivalent frame-ancestors 'none' in CSP, unless the site genuinely needs to be framed
4. X-Content-Type-Options: nosniff, which costs nothing to add and has essentially no downside

Getting this right without breaking the site, a CSP that's too strict blocks your own analytics or a legitimate third-party widget, is iterative work, which is exactly why it's a standard part of our Web & API Security Testing engagements rather than a one-time checklist item. Run your own site through the free checker as a first pass before a full assessment.