HTTP Security Headers: A Complete Guide
Everything developers need to know about HTTP security headers -- what they do, why they matter, and how to configure them correctly.
Why Security Headers Matter
HTTP security headers are directives sent by a web server in HTTP responses that instruct the browser how to behave when handling a site's content. They are one of the simplest, most effective defenses against common web attacks like cross-site scripting (XSS), clickjacking, MIME sniffing, and protocol downgrade attacks.
Adding security headers costs nothing in terms of performance and requires only a few lines of configuration in your web server or application framework. Despite this, a surprising number of production sites ship without them. This guide covers the headers that matter most, with concrete recommendations for each.
Strict-Transport-Security (HSTS)
HSTS tells the browser to always use HTTPS when connecting to your site, even if the user types http:// or clicks an HTTP link. This prevents protocol downgrade attacks where an attacker intercepts the initial HTTP request before the redirect to HTTPS.
Recommended value
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
- max-age: How long (in seconds) the browser should remember to use HTTPS. 63072000 is two years.
- includeSubDomains: Applies the policy to all subdomains, not just the apex domain.
- preload: Signals that you want your domain added to the browser's HSTS preload list, which enforces HTTPS before the first visit.
Start with a shorter max-age (e.g., 300 seconds) during testing. Once you are confident that everything works over HTTPS, increase it to two years and add preload.
Content-Security-Policy (CSP)
CSP is the most powerful security header and the most complex. It defines an allowlist of content sources -- which scripts, styles, images, and other resources the browser is permitted to load. If a resource is not on the allowlist, the browser blocks it. This is the primary defense against XSS attacks.
Example (strict policy)
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'
- default-src 'self': By default, only allow resources from the same origin.
- script-src 'self': Only allow scripts from your own domain. Avoid
'unsafe-inline'and'unsafe-eval'unless absolutely necessary. - frame-ancestors 'none': Prevents your site from being embedded in iframes (replaces X-Frame-Options).
Deploy CSP incrementally. Start with Content-Security-Policy-Report-Only to collect violation reports without blocking anything, then tighten the policy based on what you learn.
X-Frame-Options
X-Frame-Options controls whether your site can be embedded in an <iframe>. This prevents clickjacking attacks where an attacker overlays your site with invisible elements to trick users into clicking something different than what they see.
Recommended value
X-Frame-Options: DENY
Use DENY unless you need to embed your site in iframes from specific origins (in which case use SAMEORIGIN). Note that the CSP frame-ancestors directive provides the same protection with more flexibility and is the modern replacement.
X-Content-Type-Options
This header prevents browsers from MIME-sniffing a response away from the declared content type. Without it, a browser might interpret a text file as JavaScript, opening the door to XSS attacks via uploaded files.
Recommended value
X-Content-Type-Options: nosniff
There is only one valid value for this header: nosniff. It should be set on every response.
Referrer-Policy
Referrer-Policy controls how much information the browser sends in the Referer header when navigating away from your site. By default, browsers send the full URL, which can leak sensitive data in URL paths or query parameters.
Recommended value
Referrer-Policy: strict-origin-when-cross-origin
- strict-origin-when-cross-origin: Sends only the origin (not the full URL) for cross-origin requests, and sends the full URL for same-origin requests. This is a good balance between privacy and analytics functionality.
- no-referrer: For maximum privacy, sends no referrer at all. Use this if you do not rely on referrer data for analytics.
Permissions-Policy
Permissions-Policy (formerly Feature-Policy) controls which browser APIs and features your site can use. This prevents embedded third-party scripts from accessing sensitive APIs like the camera, microphone, or geolocation.
Recommended value
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()
The empty parentheses () disable the feature entirely. Only enable features your application actually uses. The interest-cohort=() directive opts out of Google's FLoC tracking (now Topics API).
Cross-Origin Headers (COOP, COEP, CORP)
These three headers work together to enable cross-origin isolation, which is required for powerful APIs like SharedArrayBuffer:
- Cross-Origin-Opener-Policy (COOP):
same-originprevents other windows from holding a reference to yours, mitigating Spectre-class attacks. - Cross-Origin-Embedder-Policy (COEP):
require-corpensures all embedded resources explicitly grant permission to be loaded. - Cross-Origin-Resource-Policy (CORP):
same-originprevents your resources from being loaded by other origins.
These headers are most important for applications that use shared memory (e.g., WebAssembly, multithreaded computations). For typical web applications, focus on the other headers first and add these when needed.
Implementation Checklist
Here is a prioritized checklist for adding security headers to your application:
- HSTS -- Enforce HTTPS (start with a short max-age).
- X-Content-Type-Options: nosniff -- One line, no configuration needed.
- X-Frame-Options: DENY -- Prevent clickjacking.
- Referrer-Policy: strict-origin-when-cross-origin -- Protect URL data in referrers.
- Permissions-Policy -- Disable unused browser APIs.
- CSP -- The most powerful header, but deploy incrementally using report-only mode first.
- Cross-origin headers -- Add when you need cross-origin isolation.
Test Your Headers
After implementing security headers, verify them against a live domain. Our Domain Intelligence Dashboard shows the status of each security header, grades them, and provides specific recommendations for any that are missing or misconfigured.
Further Reading
- OWASP Secure Headers Project
OWASP reference for HTTP security response headers and best practices.
- MDN HTTP headers
Complete reference for all HTTP headers including security-related ones.
- securityheaders.com
Free tool to scan and grade your site's HTTP security headers.