Website Security Headers: The Complete Guide (CSP, HSTS, X-Frame-Options)

HTTP security headers are one of the most overlooked aspects of website security. They're simple lines in your server configuration that can prevent a wide range of attacks — yet most websites are missing several of them. Here's everything you need to know.

What Are Security Headers?

Security headers are HTTP response headers that instruct browsers on how to handle your site's content. They tell the browser whether to allow embedding in iframes, which external resources to trust, and whether to enforce HTTPS connections. They're set at the server level and take effect on every page load.

Content-Security-Policy (CSP)

CSP is the most powerful — and most complex — security header. It defines which sources of content (scripts, styles, images, fonts) the browser is allowed to load. A properly configured CSP is one of the most effective defenses against Cross-Site Scripting (XSS), which is consistently in the OWASP Top 10.

• ✓Blocks inline scripts (a common XSS vector) unless explicitly allowed with nonces
• ✓Prevents loading of scripts from unauthorized domains
• ✓Can report policy violations to a specified endpoint for monitoring
• ✓Minimum starting point: Content-Security-Policy: default-src 'self'

Strict-Transport-Security (HSTS)

HSTS tells browsers to only connect to your site over HTTPS — even if the user types 'http://' or clicks an HTTP link. This prevents SSL stripping attacks and ensures all connections are encrypted.

• ✓Recommended value: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
• ✓The preload directive allows inclusion in browser HSTS preload lists
• ✓Do not enable before your site is fully on HTTPS — it can lock users out of HTTP fallback

X-Frame-Options

X-Frame-Options prevents your site from being embedded in iframes on other domains — protecting against clickjacking attacks, where attackers overlay invisible frames to trick users into clicking malicious content.

• ✓X-Frame-Options: DENY — never allow framing by any page
• ✓X-Frame-Options: SAMEORIGIN — only allow framing by the same domain
• ✓Modern alternative: use CSP's frame-ancestors directive for more granular control

X-Content-Type-Options

This header prevents browsers from 'sniffing' the MIME type of a response and interpreting files differently from what your server declared. Without it, a browser might execute a file uploaded as an image but containing JavaScript. Always set: X-Content-Type-Options: nosniff.

Referrer-Policy

Controls how much referrer information is included when users navigate away from your site. Without this header, the full URL (including query parameters that might contain user IDs or tokens) is sent to external sites. Recommended: Referrer-Policy: strict-origin-when-cross-origin.

Permissions-Policy

Formerly known as Feature-Policy, this header controls which browser features and APIs your page can use — camera, microphone, geolocation, payment, etc. Restricting these protects users if your site is compromised by a malicious third-party script.

How to Add Security Headers

In Next.js

Add a headers() function to your next.config.js or next.config.ts to apply security headers to all routes. This is the recommended approach for Next.js applications and takes effect on every server response.

In Vercel

Add a headers array to vercel.json with source patterns and header key-value pairs. Changes deploy automatically on your next push and apply globally to your deployment.

In Nginx

Use add_header directives in your server block. Apply them at the server level to ensure headers are sent with all responses, including static files.

Priority Order for Implementation

• ✓1. HTTPS everywhere + HSTS — foundational, must come first
• ✓2. X-Content-Type-Options: nosniff — trivial to add, high impact
• ✓3. X-Frame-Options — simple one-liner, prevents clickjacking
• ✓4. Referrer-Policy — easy, protects user privacy from leakage
• ✓5. CSP — complex but most powerful; start in report-only mode
• ✓6. Permissions-Policy — fine-tune after other headers are stable

Common Mistakes to Avoid

• ✓Setting HSTS before full HTTPS migration — locks users out of HTTP fallback
• ✓CSP that's too restrictive — breaks your own scripts and styles, causes complaints
• ✓Forgetting subdomains — headers on the main domain don't cover subdomains automatically
• ✓Not testing after adding headers — always verify with a scanner after changes