Security headers are HTTP response headers that instruct browsers how to behave when handling your site's content. Correctly configured headers can prevent entire classes of attacks, from cross-site scripting to clickjacking to protocol downgrade exploits. This guide walks through the six most important headers, with practical configuration examples for each.
1. Strict-Transport-Security (HSTS)
What it does
HSTS tells the browser to only communicate with your site over HTTPS for a specified period. Once a browser receives this header, it will automatically upgrade every HTTP request to HTTPS, even if a user manually types http://.
Why it matters
Without HSTS, an attacker on the same network can intercept the initial HTTP request before it redirects to HTTPS and perform an SSL stripping attack, serving the entire session over plain HTTP. HSTS eliminates this window of vulnerability entirely.
How to set it
Add the header in your web server or CDN configuration. Start with a short max-age (e.g. 300 seconds) to test, then increase to at least one year once confirmed.
Recommended value
- max-age=31536000 — enforce HTTPS for one year
- includeSubDomains — apply the policy to all subdomains
- preload — opt in to the browser preload list so HSTS applies on the very first visit
2. Content-Security-Policy (CSP)
What it does
CSP defines an allowlist of sources from which the browser may load scripts, styles, images, fonts, frames, and other resources. Anything not on the allowlist is blocked.
Why it matters
CSP is the single most effective defense against cross-site scripting (XSS). Even if an attacker injects a <script> tag into your page, the browser refuses to execute it unless the source is explicitly allowed in your policy.
How to set it
Start with Content-Security-Policy-Report-Only to monitor violations without breaking your site, then move to enforcement once the policy is tuned.
Example values
Strict baseline
With third-party analytics
3. X-Frame-Options
What it does
X-Frame-Options controls whether your page can be embedded inside an <iframe>, <frame>, or <object> on another site.
Why it matters
Without it, attackers can embed your page invisibly inside their own site and trick users into clicking buttons they cannot see. This technique, called clickjacking, can lead to unauthorized account actions, payment confirmations, or data disclosure.
How to set it
Add a single header to your server response. Most sites should use DENY. If you need to embed your own pages (e.g. an admin panel inside a dashboard), use SAMEORIGIN.
Recommended value
Note: The modern replacement is frame-ancestors 'none' in your CSP. Setting both provides backward compatibility with older browsers.
4. X-Content-Type-Options
What it does
This header prevents browsers from MIME-type sniffing. When set to nosniff, the browser strictly follows the Content-Type header instead of trying to detect the file type by inspecting the content.
Why it matters
Without it, an attacker could upload a file disguised as an image that actually contains JavaScript. If the browser sniffs the content and decides to treat it as a script, the malicious code runs in the context of your domain with full access to cookies and session data.
How to set it
There is only one valid value. Add it to every response.
Recommended value
5. Referrer-Policy
What it does
Controls how much information about the current page URL is included in the Referer header when a user navigates to another site or loads a third-party resource.
Why it matters
URLs often contain sensitive data: session tokens, search queries, internal page paths, or user IDs. Without a restrictive Referrer-Policy, this information leaks to every external resource and link destination on your pages.
How to set it
Add the header at the server or CDN level. The recommended value balances privacy with functionality, sending the full URL for same-origin requests but only the origin for cross-origin navigation.
Recommended value
For maximum privacy, use no-referrer. However, this breaks analytics attribution and some authentication flows.
6. Permissions-Policy
What it does
Permissions-Policy (formerly Feature-Policy) controls which browser APIs and features your page and its embedded iframes can access. You can disable the camera, microphone, geolocation, payment APIs, and dozens of other capabilities.
Why it matters
If your site embeds third-party widgets or ads, those iframes inherit access to powerful browser APIs by default. A malicious or compromised widget could silently activate the microphone, request geolocation, or trigger payment prompts. Permissions-Policy lets you revoke these capabilities for all embedded content.
How to set it
Specify each feature you want to restrict. An empty allowlist () disables the feature entirely. Use self to allow only your own origin.
Recommended value
This disables camera, microphone, geolocation, payment requests, USB access, and FLoC tracking for all contexts including embedded iframes.
Quick reference
| Header | Protects against | Difficulty |
|---|---|---|
| HSTS | SSL stripping, protocol downgrade | Easy |
| CSP | XSS, data injection, code injection | Moderate |
| X-Frame-Options | Clickjacking | Easy |
| X-Content-Type-Options | MIME confusion attacks | Easy |
| Referrer-Policy | URL data leakage | Easy |
| Permissions-Policy | Unauthorized API access via embeds | Easy |
Test your headers
Use the free headers checker to see which security headers your site is sending and get specific fix recommendations, or run a full domain scan to audit headers alongside SSL, DNS, email authentication, and more.
Check your security headers now
Free scan grades all six headers with actionable fix recommendations.
Check headers