HTTP Security Headers: CSP, HSTS and Browser Defense Guide

HTTP security headers are free, server-side response headers that instruct browsers to block entire classes of attack — cross-site scripting, clickjacking, SSL stripping, MIME sniffing — before a single line of attacker code can execute. For Indian businesses operating web applications, configuring these headers correctly is one of the highest-impact, lowest-cost hardening steps available. A misconfigured or absent header is a finding on every VAPT report, graded from Medium to Critical depending on the header and the attack it leaves open. This article covers each key header, what it defends against, recommended values, and how to roll out the hardest one (CSP) without breaking your site.

Why HTTP Security Headers Matter

When your server returns a response, it can include instructions telling the browser how to handle that response. These instructions live in HTTP response headers. They cost nothing to add — no external service, no library, no certificate purchase. Yet the OWASP Secure Headers Project lists their absence as one of the most consistently observed weaknesses across web applications globally.

Without them, the browser operates in a permissive default mode: it will execute any inline JavaScript, load resources from any origin, allow your page to be framed by any domain, and happily downgrade from HTTPS to HTTP if an attacker intercepts the connection. Each of those defaults is a threat vector.

The Full Header Map: Threat, Header, Value

The table below maps each header to the threat it addresses and the recommended configuration for production.

Content-Security-Policy: The Hardest but Most Powerful

Content-Security-Policy (CSP) tells the browser which sources are trusted for scripts, styles, images, fonts, and other resource types. A correctly implemented CSP eliminates the entire family of reflected, stored, and DOM-based XSS attacks by preventing the browser from executing unauthorised scripts — even if the attacker has already injected the payload.

The directive that matters most is script-src. Without it, a single XSS payload can steal session cookies, exfiltrate form data, or inject malicious UI.

Rolling Out CSP Without Breaking Your Site

The biggest operational risk with CSP is accidentally blocking your own scripts. The safe rollout path:

1. Start with Content-Security-Policy-Report-Only and set a report-uri or report-to endpoint. The browser enforces nothing but sends violation reports. Collect these for one to two weeks.
2. Eliminate unsafe-inline by replacing inline scripts with external .js files, or by adding a cryptographic nonce ('nonce-<random>') or hash ('sha256-<hash>') to each inline block. Every inline <script> without a nonce or hash is a CSP bypass.
3. Move to enforcement mode by switching the header name to Content-Security-Policy.
4. Add upgrade-insecure-requests to force mixed-content resources to HTTPS automatically.

Strict-Transport-Security: Locking In HTTPS

HSTS tells browsers that your domain must only be contacted over HTTPS, for the duration specified in max-age. Once a browser has seen this header, it will internally redirect HTTP requests to HTTPS before they leave the machine — the attacker never gets to intercept the plain-text request.

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

1. max-age=31536000 — one year; browser remembers the policy even after clearing cache.
2. includeSubDomains — extends the policy to all subdomains. Required for preload submission.
3. preload — signals your intent to be included in the HSTS preload list maintained by Google (used by all major browsers). Submit your domain at hstspreload.org.

The attack HSTS defeats is SSL stripping, where a network-level attacker (on public Wi-Fi, a compromised router, or via ARP poisoning) downgrades your user's HTTPS connection to plain HTTP and reads session tokens and credentials in transit. Without HSTS, a valid HTTPS certificate alone does not prevent this.

X-Frame-Options and frame-ancestors: Stopping Clickjacking

Clickjacking loads your site invisibly inside an <iframe> on an attacker's page, then tricks the victim into clicking buttons on your site — authorising payments, changing passwords, approving transactions — without realising it.

X-Frame-Options: DENY prevents your page from being framed by any origin. SAMEORIGIN allows framing only from your own domain. For modern stacks, the CSP directive frame-ancestors 'none' or frame-ancestors 'self' achieves the same result with finer control and supersedes X-Frame-Options in browsers that support CSP Level 2. Include both for maximum compatibility.

X-Content-Type-Options: Blocking MIME Sniffing

Browsers historically tried to be "helpful" by guessing a file's content type even when the server declared otherwise — a behaviour called MIME sniffing. Attackers exploited this by uploading an image file containing JavaScript and getting old browsers to execute it.

X-Content-Type-Options: nosniff is a one-liner that instructs the browser to trust the Content-Type header and refuse to sniff. It is a trivial change with zero downside.

Referrer-Policy: Preventing URL Leakage

When a user navigates from your site to an external link, the browser sends the originating URL in the Referer header. If that URL contains a session token, a password-reset token, or a sensitive resource identifier, you have just handed it to a third-party server.

Referrer-Policy: strict-origin-when-cross-origin sends only the origin (not the path or query string) on cross-origin requests, while preserving the full referrer for same-origin navigation — the sensible default for most applications.

Permissions-Policy: Restricting Browser APIs

Permissions-Policy (formerly Feature-Policy) controls which browser APIs the page and its embedded iframes are allowed to access. An attacker who achieves XSS can use the camera, microphone, or geolocation APIs if the site has not explicitly restricted them.

Example for a site that needs none of these:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Each empty parenthesis means the feature is disabled for all origins, including iframes.

X-XSS-Protection: Deprecated — Disable It

The legacy X-XSS-Protection header enabled a reflective XSS filter in older IE and Chrome browsers. Modern browsers have removed the filter, and keeping the header set to 1; mode=block can actually introduce new vulnerabilities in some browser versions. The correct value today is X-XSS-Protection: 0 — explicitly disable it and rely on CSP for XSS mitigation.

How a VAPT Scan Grades Security Headers

Automated header scanning — as part of a VAPT or a standalone header check — evaluates each header against known-good configurations:

1. Missing HSTS → Medium (potential SSL stripping; upgraded to High on login pages)
2. Missing or weak CSP (e.g., unsafe-inline present) → Medium to High
3. Missing X-Frame-Options / frame-ancestors → Medium (clickjacking risk)
4. Missing X-Content-Type-Options → Low to Medium
5. Missing Referrer-Policy → Low
6. X-XSS-Protection set to 1 → Informational to Low (deprecated header present)

Common Mistakes to Avoid

1. Setting headers only on the login page. Every page that loads authenticated content needs the full header set.
2. Using default-src * in CSP. A wildcard source allowlist defeats the purpose entirely.
3. Adding HSTS with a short max-age (e.g., 300 seconds). This offers no real protection — attackers wait out short durations.
4. Skipping includeSubDomains on HSTS when you have authentication on subdomains. An attacker can still strip HTTPS on api.yourdomain.com.
5. Not testing after deployment. Use securityheaders.com or the OWASP Secure Headers Project scanner to verify your live header output before closing the ticket.
6. Trusting framework defaults. Next.js, Django, and Rails have varying defaults — verify with a real HTTP response inspector, not just config files.

Putting It Together: A Deployment Checklist

Authoritative References

1. OWASP Secure Headers Project — canonical header guidance with grading criteria
2. MDN Web Docs — HTTP Headers — per-header syntax, browser support, and directive reference
3. CERT-In Annual Report 2023 — Indian incident statistics and web application threat landscape
4. HSTS Preload Submission — official preload list maintained by Google Chrome