HTTP Security Headers:
The Complete Developer Guide

Why HTTP Security Headers Matter

HTTP security headers are response headers that instruct the browser how to behave when handling your site's content. They are one of the highest-value, lowest-effort security controls available — most take under five minutes to implement and protect against entire vulnerability classes including XSS, clickjacking, protocol downgrade attacks, and MIME-type confusion.

Despite this, they are consistently absent. A scan of the Alexa top 1 million sites finds that over 95% are missing at least one critical security header. Scanner tools like securityheaders.com give most production applications a grade of D or F.

Content-Security-Policy (CSP)

CSP is the most powerful — and most complex — security header. It defines which sources of content (scripts, styles, images, fonts, frames) the browser is permitted to load. A properly configured CSP eliminates the impact of most XSS attacks by preventing injected scripts from executing.

# Strict CSP — adjust sources to match your actual CDN/fonts
add_header Content-Security-Policy
  "default-src 'self';
   script-src 'self' 'nonce-{RANDOM}';
   style-src 'self' 'nonce-{RANDOM}' fonts.googleapis.com;
   font-src 'self' fonts.gstatic.com;
   img-src 'self' data: cdn.yoursite.com;
   connect-src 'self' api.yoursite.com;
   frame-ancestors 'none';
   base-uri 'self';
   form-action 'self';
   upgrade-insecure-requests";

Start with report-only mode

CSP is notoriously easy to break in production. Start with Content-Security-Policy-Report-Only and a report-uri endpoint. Run it for two weeks, fix all the legitimate violations, then switch to enforcement mode.

Strict-Transport-Security (HSTS)

HSTS tells browsers to only ever connect to your domain over HTTPS — even if the user types http:// or follows an HTTP link. Once a browser has seen an HSTS header, it will internally redirect to HTTPS before making any network request for the specified duration.

# Two-year max-age, include subdomains, opt into preload list
add_header Strict-Transport-Security
  "max-age=63072000; includeSubDomains; preload" always;

The preload directive allows your domain to be added to Chrome's HSTS preload list — a hardcoded list of domains that Chrome connects to over HTTPS before ever seeing the header. Submit at hstspreload.org.

X-Frame-Options

X-Frame-Options prevents your pages from being embedded in iframes on other sites, mitigating clickjacking attacks. Clickjacking places an invisible iframe of your site over a deceptive UI to trick users into clicking on your buttons.

add_header X-Frame-Options "DENY" always;
# Or SAMEORIGIN if you need to iframe your own pages:
# add_header X-Frame-Options "SAMEORIGIN" always;

X-Content-Type-Options

Without this header, browsers perform MIME-type sniffing — inferring the content type from the content itself rather than the Content-Type header. An attacker can upload a file that looks like an image but contains JavaScript, and the browser might execute it.

add_header X-Content-Type-Options "nosniff" always;

This is the simplest header to set and has essentially zero risk of breaking anything. There is no legitimate reason not to have it.

Referrer-Policy

When a user clicks a link from your site to an external site, the browser sends a Referer header containing the full URL of the page they were on. This can leak sensitive path information — user IDs, session tokens in URLs, or internal path structure.

# Send origin only for same-origin, nothing for cross-origin
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

• no-referrer — never send the Referer header (breaks some analytics)
• strict-origin-when-cross-origin — send full URL same-origin, just the origin cross-origin (recommended)
• same-origin — only send Referer for same-origin requests

Permissions-Policy

Formerly Feature-Policy, this header controls which browser features and APIs your page (and embedded iframes) can use — camera, microphone, geolocation, payment, and more. Restricting unused APIs reduces the attack surface for malicious third-party scripts.

# Disable everything you don't use
add_header Permissions-Policy
  "camera=(), microphone=(), geolocation=(), payment=(),
   usb=(), bluetooth=(), interest-cohort=()" always;

Remove the Server Header

By default, web servers advertise their name and version in the Server header (Server: nginx/1.18.0 or Server: Apache/2.4.51). This helps attackers identify unpatched software versions instantly.

server_tokens off;  # nginx: removes version from Server header
# Apache: ServerTokens Prod + ServerSignature Off

Also remove or sanitize X-Powered-By (often set by frameworks to e.g. PHP/8.1.2). In Express.js: app.disable('x-powered-by').

Testing Your Security Headers

After deployment, verify your header configuration:

# Check headers with curl
curl -I https://yoursite.com

# Check specific header
curl -s -I https://yoursite.com | grep -i "content-security-policy"

# Full header audit — securityheaders.com API
curl "https://securityheaders.com/?q=yoursite.com&followRedirects=on"

• securityheaders.com — grades your header configuration, explains each finding
• Mozilla Observatory — comprehensive header and TLS analysis
• OWASP ZAP — includes passive header checks in every scan
• AquilaX DAST — checks headers as part of automated security scanning in CI/CD

Security Headers Checklist

1. Content-Security-Policy — deployed in report-only, then enforcement; no unsafe-inline
2. Strict-Transport-Security — max-age ≥ 1 year, includeSubDomains if safe
3. X-Frame-Options: DENY (or SAMEORIGIN) — plus frame-ancestors in CSP
4. X-Content-Type-Options: nosniff — zero risk, always set
5. Referrer-Policy: strict-origin-when-cross-origin — stops URL leakage
6. Permissions-Policy — disable camera, mic, geolocation, payment if not used
7. Remove or sanitize Server and X-Powered-By headers
8. Verify with securityheaders.com and Mozilla Observatory after each deployment