HTTP Security Headers Explained: What Every Website Should Set

Hero Summary

HTTP security headers are instructions a web server sends with each response that tell the browser how to behave — for example, to use only HTTPS, to refuse to be embedded in another site, or to load scripts only from approved sources. They are a low-cost layer of defense against attacks such as cross-site scripting (XSS), clickjacking, and protocol downgrade. The core set is Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, frame-ancestors (or X-Frame-Options), Referrer-Policy, and Permissions-Policy. Headers are not a substitute for secure code, but missing or misconfigured headers are among the most common and easily fixed web security findings.

Executive Summary

Security headers move some protection from application code to the browser. They are quick to deploy but easy to get wrong: an over-strict policy can break a site, and a long-lived HSTS setting with a certificate problem can lock users out. This guide explains each important header, the settings OWASP recommends, the headers that are obsolete and should not be relied on, how to roll out changes safely, how to test them, and how they fit with penetration testing. Guidance is based on the OWASP HTTP Headers Cheat Sheet and related OWASP and MDN documentation.

What security headers do {#what}

A browser makes security decisions based on the headers it receives. Security headers let a site owner switch on protections the browser already has: restrict where scripts can load from, force encrypted connections, block risky content-type guessing, and stop other sites from framing the page. They apply to responses that browsers render, so they matter most for web pages; for APIs consumed only by non-browser clients, most have little effect.

Content-Security-Policy {#csp}

Content-Security-Policy (CSP) tells the browser which sources of scripts, styles, images, frames, and other resources are allowed. A strict CSP is one of the strongest defenses against cross-site scripting, because even if an attacker injects a script tag, the browser refuses to run it if it does not come from an allowed source.

OWASP suggests a basic starting policy of default-src 'self'; frame-ancestors 'self'; form-action 'self'; and recommends a stricter approach that uses nonces or hashes for scripts, which provides a robust mitigation against XSS. Practical points:

• Avoid 'unsafe-inline' and 'unsafe-eval' for scripts where possible; they remove much of the protection.
• Inventory the third-party scripts, fonts, and tags the site loads, because each must be allowed or it will break.
• Use report-only mode first (Content-Security-Policy-Report-Only) to see what would be blocked before enforcing.

Strict-Transport-Security (HSTS) {#hsts}

HSTS tells the browser to only connect to the site over HTTPS for a set period, which defeats protocol-downgrade and cookie-hijacking attacks on first-party connections. The OWASP HTTP Headers Cheat Sheet recommends Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (two years), with these cautions:

• Start small. Begin with a short max-age, such as 86400 (one day), while you confirm everything works over HTTPS.
• includeSubDomains applies the policy to every subdomain. All must support HTTPS before you enable it.
• preload is a serious commitment. It can prevent users reaching your site and subdomains if you ever need to revert to HTTP.
• Certificate problems become lockouts. An expired or revoked certificate combined with a long max-age can block legitimate users for the full duration, so monitor certificate expiry. See What Is Domain Security?.

X-Content-Type-Options {#nosniff}

X-Content-Type-Options: nosniff stops the browser from guessing a response's content type, which prevents "MIME confusion" attacks in which, for example, an uploaded file is interpreted as a script. It only helps if the server also sends correct Content-Type headers.

Clickjacking protection: frame-ancestors and X-Frame-Options {#framing}

Clickjacking tricks a user into clicking something on a hidden, framed copy of your page. The modern defense is the CSP directive frame-ancestors: OWASP's guidance is that it obsoletes X-Frame-Options for supporting browsers and recommends using it where possible, with frame-ancestors 'none' blocking all framing unless a specific need exists, or 'self' to allow only your own site. frame-ancestors is ignored if set in a <meta> tag, so it must be sent as an HTTP header. Many sites still send X-Frame-Options: DENY as well, for older browsers.

Referrer-Policy {#referrer}

When a user follows a link, the browser may send the previous page's address in the Referer header, which can leak sensitive URLs. Referrer-Policy controls how much is sent. A common, balanced choice is strict-origin-when-cross-origin, which sends the full path only within the same site and only the origin to other sites, and nothing when moving from HTTPS to HTTP. Use no-referrer for pages where even the origin should not be shared.

Permissions-Policy {#permissions}

Permissions-Policy lets a site disable browser features it does not use — such as camera, microphone, geolocation, or payment — and control which embedded frames may use them. Disabling unneeded features reduces what an injected script or a third-party embed could abuse.

Headers to remove or not rely on {#obsolete}

• X-XSS-Protection is deprecated and has been removed from major browsers. OWASP's guidance is not to rely on it — either leave it unset or explicitly set it to 0 — and to use a strict CSP instead, because the old filter could itself introduce vulnerabilities.
• Server, X-Powered-By, and similar headers reveal software and version information that helps attackers. Remove or minimize them.
• Headers that duplicate or conflict with each other, such as different policies set by the application and the CDN, should be consolidated.

Rolling out safely {#rollout}

1. Inventory current headers on each domain and subdomain, including those set by CDNs, proxies, and the application.
2. Start with low-risk headers such as X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
3. Deploy CSP in report-only mode, review reports, fix or allow legitimate sources, then enforce.
4. Introduce HSTS gradually — short max-age first, then increase, and add includeSubDomains and preload only when ready.
5. Apply headers consistently, including error pages and static assets.
6. Monitor for breakage and for changes — a platform update can silently drop a header.

Testing your headers {#testing}

Inspect a response in your browser's developer tools (Network tab) or fetch headers with a command-line tool, and use an online header analyzer for a quick score. A scanner shows what is present, not whether the policy is effective: a CSP that allows 'unsafe-inline' or wildcard sources may be "present" but weak. Penetration testing validates whether headers actually prevent attacks. See Web Application VAPT and Website Vulnerability Management.

How Threat ResQ fits {#threat-resq-fit}

Threat ResQ's VAPT service covers vulnerability assessment and penetration testing, with retest included on all critical findings, delivered in collaboration with a CERT-In empanelled security firm; the empanelment belongs to that partner, not to Threat ResQ itself. DomainShield IQ, its domain security platform, monitors SSL/TLS certificate lifecycle with expiry alerts, DNS records, and domain and subdomain exposure — relevant to HSTS, where certificate problems can lock users out.

FAQ {#faq}

What are HTTP security headers? Response headers that instruct the browser to apply security protections, such as enforcing HTTPS, restricting which sources can load scripts, preventing content-type sniffing, and blocking framing by other sites.

Which security headers are the most important? Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, frame-ancestors (with X-Frame-Options for older browsers), Referrer-Policy, and Permissions-Policy.

Is X-Frame-Options still needed? The CSP frame-ancestors directive obsoletes it for supporting browsers, but some sites keep X-Frame-Options for older browsers. If you set both, keep them consistent.

Should I set X-XSS-Protection? No. It has been removed from major browsers. OWASP advises leaving it unset or setting it to 0 and relying on a strict Content-Security-Policy.

Can security headers break my website? Yes. An overly strict CSP can block legitimate scripts, and a long HSTS lifetime combined with a certificate problem can lock users out. Roll out gradually, use CSP report-only mode first, and start HSTS with a short max-age.