HTTP Security Headers: Complete Guide to CSP, HSTS, X-Frame-Options and More

HTTP security headers are powerful mechanisms that protect your website from attacks like XSS, CSRF, and clickjacking. Despite their importance, most websites don't implement them properly, leaving user data vulnerable. This guide explains each header in detail, how to configure them, and how to verify they're working correctly for your site.

What Are HTTP Security Headers and Why Every Website Needs Them

HTTP security headers are directives that servers send in HTTP responses to tell browsers how to handle security concerns. They protect against XSS attacks, MIME sniffing, clickjacking, and referrer leakage. These headers act as an additional security layer even if you've already hardened your code, giving extra confidence that attackers can't easily compromise your users.

• Prevent XSS attacks by controlling which content sources are allowed
• Enforce HTTPS across your entire site using HSTS
• Block clickjacking by restricting iframe embedding
• Control referrer data leakage to other websites
• Prevent unsafe MIME type sniffing by browsers
• Restrict plugin, microphone, and camera access from untrusted sources

Content-Security-Policy (CSP) – Fine-Grained Content Control

Content-Security-Policy is the most powerful header for preventing XSS attacks. It lets you specify which domains can load scripts, stylesheets, images, fonts, and other resources. CSP can enforce restrictions or run in report-only mode to warn you about violations without breaking functionality. Start with report-only mode to test policies before enforcing them.

• default-src 'self' restricts resources to your domain only
• script-src controls where JavaScript can be loaded from
• style-src limits CSS sources to approved locations
• img-src specifies which domains can serve images
• font-src restricts font loading to trusted sources
• frame-ancestors 'none' prevents clickjacking attacks

HSTS (Strict-Transport-Security) – Enforce HTTPS Always

HSTS tells browsers to always connect to your site via HTTPS, even if users type HTTP URLs or click old links. It prevents downgrade attacks and man-in-the-middle interception. The header includes max-age (how long browsers remember this policy) and an optional includeSubDomains directive that extends the policy to all subdomains.

• Protects against downgrades from HTTPS to HTTP due to network interception
• Tells browsers to remember this policy for years if configured
• Optional includeSubDomains extends protection to all subdomains
• Reduces redundant 301 HTTP-to-HTTPS redirects on every visit
• Prevents eavesdropping and tampering with unencrypted traffic

X-Content-Type-Options and X-Frame-Options – Prevent MIME Sniffing and Clickjacking

X-Content-Type-Options: nosniff tells browsers to trust the Content-Type header you send and not guess file types. Without it, browsers might interpret files as HTML despite your explicit content type. X-Frame-Options: DENY prevents your site from being embedded in iframes on other websites, blocking clickjacking attacks where hidden buttons trick users into unintended actions.

• X-Content-Type-Options: nosniff blocks MIME sniffing attacks completely
• X-Frame-Options: DENY prevents all iframe embedding of your site
• X-Frame-Options: SAMEORIGIN allows iframe embedding only from your own domain
• X-Frame-Options: ALLOW-FROM (deprecated) used to whitelist other trusted domains
• Both headers are simple but extremely effective at stopping common attacks

Referrer-Policy and Permissions-Policy – Control Referrer Data and Browser Features

Referrer-Policy controls how much referrer information (the URL the user came from) is sent to other websites. For example, strict-origin-when-cross-origin sends only the domain name, not the full URL or query parameters. Permissions-Policy (formerly Feature-Policy) restricts scripts and third-party iframes from accessing sensitive browser APIs like camera, microphone, location, and payment requests.

• Referrer-Policy: strict-origin-when-cross-origin sends only domain across origins
• Referrer-Policy: no-referrer prevents all referrer information from being sent
• Referrer-Policy: same-origin only sends referrer within your own site
• Permissions-Policy: camera=() disables camera access from scripts
• Permissions-Policy: geolocation=() prevents location tracking
• Permissions-Policy: payment=() blocks payment request API access

How to Add Security Headers – Apache .htaccess and Nginx Examples

Adding headers to your site is straightforward. On Apache, add directives to your .htaccess file in the root directory. On Nginx, edit your nginx.conf or virtual server config file. If you use PHP, you can add headers with the header() function, but must do so before any HTML output. Start with simple headers like X-Content-Type-Options and X-Frame-Options, then gradually add the more complex CSP.

• Apache: wrap directives in blocks in .htaccess
• Nginx: add header directives inside your server {} block
• PHP: use header() function but place it before any output
• Start with simple headers before progressing to complex CSP
• Test in report-only mode before enforcing policies
• Restart your server or reload configuration files to apply changes

Test Your Headers with Online Scanning Tools

After setting up headers, test to ensure browsers actually receive them. Several free online tools scan your headers and provide security ratings. The easiest method is opening your browser's developer tools (F12), going to the Network tab, and checking the Response headers sent by your site. You can also use the curl command-line tool to fetch headers without loading a full page.

• Use free online header scanning tools to check all headers at once
• Open developer tools (F12) and navigate to the Network tab
• Inspect Response headers for each page load
• Use curl from terminal to quickly check headers
• Watch browser console for Content-Security-Policy violation errors
• Adjust headers if tests reveal missing or incorrect directives

Common CSP Mistakes That Break Your Website

Overly strict CSP policies often break parts of your site – scripts won't load, styles disappear, or iframes fail to render. Common mistakes include forgetting to whitelist public CDN domains in script-src, using 'unsafe-inline' which reduces security, forgetting to allow data: URLs for base64-encoded images, or shutting down default-src but forgetting other directives. When broken, use report-only mode to diagnose issues via console errors, then gradually relax the policy.

• Forgetting to whitelist CDN domains in script-src
• Using 'unsafe-inline' which defeats CSP's purpose
• Failing to allow data: URLs for embedded images or fonts
• Blocking default-src but forgetting other source directives
• Not checking console errors before enforcing strict policies
• Using report-only mode first to test and adjust policies
• Gradually tightening policies instead of relaxing too quickly

Security Headers vs SSL Certificate – What Each One Actually Protects

SSL certificates and security headers protect against different threats. SSL encrypts data between browser and server, preventing eavesdropping and network-level man-in-the-middle attacks. Security headers work after data arrives safely by telling browsers to prevent XSS, CSRF, clickjacking, and feature abuse. You need both: SSL for encryption, security headers for application-level defense. Without both, your site has holes.

• SSL Certificate encrypts data in transit to prevent network interception
• Security Headers prevent application-level attacks like XSS and CSRF
• SSL protects against ISP and Wi-Fi network eavesdropping
• CSP prevents injection attacks even if SSL is configured correctly
• HSTS enforces HTTPS but cannot fix vulnerable application code
• Both SSL certificates and security headers are essential for complete protection