HTTP Security Headers Explained: The Essential Set for 2026
A practical guide to the HTTP security headers every website should have — Content-Security-Policy, HSTS, X-Frame-Options, Referrer-Policy, and Permissions-Policy — with implementation examples.
What security headers do
HTTP response headers are instructions your web server sends to the browser alongside each page. Security headers tell the browser how to handle your content: whether it can be framed by other sites, what scripts are allowed to run, whether to enforce HTTPS, and what information to send in the Referer header.
They are the last line of defence against a range of client-side attacks — XSS, clickjacking, mixed content, and data leakage. They are also free and take minutes to configure.
The essential headers
Strict-Transport-Security (HSTS)
Tells browsers to only connect to your site over HTTPS, even if the user types http://. Prevents SSL stripping attacks where an attacker downgrades your connection on a shared network.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Important: only add preload once you are confident all your subdomains support HTTPS. Preloaded domains are hardcoded into browsers and can take months to remove.
Content-Security-Policy (CSP)
Defines which resources (scripts, styles, images, fonts) the browser is allowed to load and from where. A properly configured CSP is the most effective defence against cross-site scripting (XSS).
A strict starting point:
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none'; base-uri 'self';
CSP is complex to get right without breaking things. Start with Content-Security-Policy-Report-Only to observe violations before enforcing.
X-Frame-Options
Prevents your pages from being embedded in iframes on other sites — the attack vector for clickjacking, where a victim is tricked into clicking something invisible overlaid on a legitimate-looking page.
X-Frame-Options: DENY
Note: this header is superseded by CSP's frame-ancestors directive in modern browsers, but it is still required for older browsers and is considered best practice to include both.
X-Content-Type-Options
Stops browsers from MIME-sniffing — guessing the content type of a response. Without it, a browser might interpret a plain text file as executable JavaScript if it looks like script. Always set:
X-Content-Type-Options: nosniff
Referrer-Policy
Controls how much information is included in the Referer header when users follow links from your site. Without it, users clicking from your secure admin panel to an external site will leak the full URL — potentially including sensitive identifiers.
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy
Controls access to browser APIs — camera, microphone, geolocation, payment — for your pages and any iframes they contain. A good default if you do not need these features:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
Where to set them
Security headers can be set at multiple layers:
- Web server config (nginx, Apache) — applied to all responses, easiest to maintain
- CDN/edge (Cloudflare, Vercel, CloudFront) — good for static sites; Cloudflare has a one-click HSTS and managed headers feature
- Application code (middleware in Next.js, Django, Laravel) — useful when headers need to vary per route
Mozilla Observatory
Mozilla Observatory grades your security headers from A+ to F and explains exactly what is missing. VP Shield checks your Observatory score as part of every passive domain scan — along with the other five security checks — so you get a complete picture in one place.