HTTP Security Headers: The Complete 2026 Checklist (+ Free Scanner Tool)

Every HTTP response your web server sends includes headers — metadata that tells the browser how to handle the content. Most developers think of headers as mundane plumbing: cache directives, content types, cookie attributes. But a specific subset of HTTP response headers exists solely to instruct browsers to activate built-in security mechanisms that protect your users from cross-site scripting, clickjacking, data injection, protocol downgrade attacks, and a dozen other threats.

These are security headers, and they are one of the most cost-effective defenses available to any web application. They require no code changes to your application logic. They cost nothing to implement. They take effect instantly for every user whose browser supports them — which, in 2026, is effectively all of them. Yet an alarming number of production websites still ship responses with none of these headers configured.

This guide covers every security header you should be setting in 2026, explains exactly what each one protects against, provides implementation examples for four major server platforms, and points you to a free online scanner that checks any website's headers in seconds.

Why Security Headers Matter in 2026

The modern browser is not a dumb document viewer. It is a sophisticated runtime environment that executes JavaScript, renders cross-origin resources, manages credentials, handles service workers, and maintains complex state across dozens of open tabs. This power comes with a vast attack surface. Security headers exist to constrain that attack surface by telling the browser which behaviors are legitimate for your application and which should be blocked.

Without security headers, browsers fall back to their default behavior — which is almost always the most permissive option. Your page can be framed by any domain. Scripts from any origin can execute in your context. The browser will happily sniff content types, follow protocol downgrades, and leak referrer information to third parties. Every one of these defaults is a vector that attackers routinely exploit.

The Cost of Missing Headers

Security headers are not optional hardening for high-security applications. They are baseline hygiene. Here is what missing headers cost organizations in practice:

• Clickjacking lawsuits: Without X-Frame-Options or a CSP frame-ancestors directive, attackers embed your login page inside an invisible iframe and trick users into entering credentials on a fake site. Financial institutions have faced class-action suits over this exact scenario.
• XSS amplification: Without Content-Security-Policy, a single reflected XSS vulnerability becomes a full account takeover because the injected script can load external payloads, exfiltrate cookies, and communicate with attacker-controlled servers without restriction.
• Protocol downgrade attacks: Without Strict-Transport-Security, an attacker on a shared Wi-Fi network can strip HTTPS from your connections and intercept everything in plaintext, even if your server is configured for HTTPS only.
• Compliance failures: PCI DSS 4.0, HIPAA technical safeguards, and SOC 2 common criteria all reference transport security and access controls that security headers directly enforce. Missing headers are audit findings.
• Penetration test failures: Every professional penetration test report includes a section on missing security headers. They are low-hanging findings that signal broader security immaturity to assessors.

The 10 Essential Security Headers Critical

The following ten headers represent the complete security header baseline for any production web application in 2026. Each one addresses a distinct threat category. Implementing all ten creates a layered defense that significantly raises the bar for attackers.

1. Content-Security-Policy (CSP)

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{random}';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' https://api.yourdomain.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  upgrade-insecure-requests;

Key directives: default-src sets the fallback policy. script-src controls JavaScript execution — use nonces or hashes instead of 'unsafe-inline'. frame-ancestors replaces X-Frame-Options with more granular control. upgrade-insecure-requests automatically upgrades HTTP resource requests to HTTPS.

Common mistake: Setting script-src 'self' 'unsafe-inline' 'unsafe-eval' defeats the entire purpose of CSP. If you allow inline scripts and eval, an XSS payload will execute just as easily as without CSP.

2. Strict-Transport-Security (HSTS)

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Best practice: Set max-age to at least two years (63,072,000 seconds). Include the includeSubDomains directive to protect all subdomains. Add preload and submit your domain to the HSTS preload list so browsers enforce HTTPS from the very first visit, before even receiving the header.

Common mistake: Setting a short max-age like 300 seconds "for testing" and forgetting to increase it. A five-minute HSTS window provides almost no protection because the attacker only needs to catch the user outside that window.

3. X-Frame-Options

X-Frame-Options: DENY

Values: DENY prevents all framing. SAMEORIGIN allows framing only by pages on the same origin. The ALLOW-FROM directive was never widely supported and is now deprecated. For granular framing control, use the CSP frame-ancestors directive instead.

Note: While CSP frame-ancestors is the modern replacement, X-Frame-Options should still be set for backward compatibility with older browsers that do not support CSP Level 2.

4. X-Content-Type-Options

X-Content-Type-Options: nosniff

This header has exactly one valid value: nosniff. It is trivial to implement and has no legitimate reason to be omitted. If your security header scan reports this one missing, it is a clear indicator that headers have not been configured at all.

5. Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Values explained: no-referrer sends nothing. strict-origin-when-cross-origin sends only the origin (not the full URL path) on cross-origin requests and nothing on HTTPS-to-HTTP downgrades. same-origin sends the full referrer only to same-origin destinations. For most applications, strict-origin-when-cross-origin provides the best balance of privacy and functionality.

6. Permissions-Policy

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=(), interest-cohort=()

Syntax: Each feature is set to a list of allowed origins. An empty list () disables the feature entirely. (self) allows only the current origin. (self "https://trusted.com") allows the current origin and a specific trusted domain. The interest-cohort=() directive opts out of Federated Learning of Cohorts (FLoC) and related tracking APIs.

7. X-XSS-Protection

X-XSS-Protection: 0

Why set it to 0? The value 1; mode=block was historically recommended, but the XSS Auditor itself could be exploited to selectively disable scripts on a page, enabling information leakage and bypass attacks. Setting 0 explicitly disables the broken filter. Rely on CSP for XSS prevention instead. This header is included for completeness and to prevent older browsers from activating the flawed auditor.

8. Cross-Origin-Opener-Policy (COOP)

Cross-Origin-Opener-Policy: same-origin

Values: same-origin isolates your page from all cross-origin openers and openees. same-origin-allow-popups allows your page to open cross-origin popups while still preventing them from obtaining a reference back. unsafe-none is the legacy default with no isolation. For most applications, same-origin is the correct choice.

9. Cross-Origin-Resource-Policy (CORP)

Cross-Origin-Resource-Policy: same-origin

Values: same-origin restricts loading to the same origin only. same-site allows loading from the same registrable domain (e.g., cdn.example.com can load from api.example.com). cross-origin allows any origin (useful for public CDNs). For application pages and API responses, use same-origin. For intentionally public resources served from a CDN, cross-origin is appropriate.

10. Cache-Control for Sensitive Pages

# For authenticated/sensitive pages:
Cache-Control: no-store, no-cache, must-revalidate, private
Pragma: no-cache

# For public static assets (CSS, JS, images):
Cache-Control: public, max-age=31536000, immutable

Key distinction: no-store tells caches to never store the response at all. no-cache tells caches to revalidate with the server before serving. private prevents shared (proxy) caches from storing the response. For sensitive pages, use all three together. The Pragma: no-cache header is included for compatibility with HTTP/1.0 proxies.

How to Check Your Headers

Knowing which headers to set is only half the battle. You also need to verify that they are present, correctly configured, and actually being served in production. Here are three methods, ranging from manual to automated.

Method 1: Browser Developer Tools

Open your browser's developer tools (F12), navigate to the Network tab, select the main document request, and inspect the Response Headers section. This shows you exactly what the server sent. The limitation is that you must manually check each header and know what the correct values should be.

Method 2: Command Line with curl

# Fetch only the response headers for any URL
curl -I https://your-website.com

# Example output (abbreviated):
HTTP/2 200
content-type: text/html; charset=utf-8
strict-transport-security: max-age=63072000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self'
x-frame-options: DENY
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=()

This is fast and scriptable, but requires you to know which headers to look for and what values are considered secure.

Method 3: Free Security Factor 365 Header Scanner

The fastest and most comprehensive method is to use an automated scanner that checks all security headers at once and grades each one. The Security Factor 365 Website Security Header Scanner is free, requires no registration, and analyzes any publicly accessible URL in seconds.

The scanner checks for all 10 headers covered in this article, evaluates the quality of each header's configuration (not just its presence), and provides specific remediation guidance for any missing or misconfigured headers. It also flags common misconfigurations like overly permissive CSP directives or short HSTS max-age values.

Implementation Guide: Adding Security Headers to Your Server

The implementation approach depends on your web server or application framework. Below are complete, copy-ready configurations for the four most common platforms. Each example sets all 10 security headers discussed in this article.

Apache (.htaccess or httpd.conf)

# Enable headers module (if not already enabled)
# a2enmod headers

<IfModule mod_headers.c>
    # Content-Security-Policy
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests"

    # HSTS - 2 years with subdomains and preload
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

    # Clickjacking protection
    Header always set X-Frame-Options "DENY"

    # MIME sniffing protection
    Header always set X-Content-Type-Options "nosniff"

    # Referrer policy
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Permissions policy
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()"

    # Disable legacy XSS auditor
    Header always set X-XSS-Protection "0"

    # Cross-origin isolation
    Header always set Cross-Origin-Opener-Policy "same-origin"
    Header always set Cross-Origin-Resource-Policy "same-origin"
</IfModule>

# Cache control for sensitive pages
<FilesMatch "\.(html|php)$">
    Header always set Cache-Control "no-store, no-cache, must-revalidate, private"
    Header always set Pragma "no-cache"
</FilesMatch>

Nginx (nginx.conf or server block)

server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    # Content-Security-Policy
    add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests" always;

    # HSTS - 2 years with subdomains and preload
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # Clickjacking protection
    add_header X-Frame-Options "DENY" always;

    # MIME sniffing protection
    add_header X-Content-Type-Options "nosniff" always;

    # Referrer policy
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Permissions policy
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()" always;

    # Disable legacy XSS auditor
    add_header X-XSS-Protection "0" always;

    # Cross-origin isolation
    add_header Cross-Origin-Opener-Policy "same-origin" always;
    add_header Cross-Origin-Resource-Policy "same-origin" always;

    # Cache control for dynamic content
    location ~ \.(html|php)$ {
        add_header Cache-Control "no-store, no-cache, must-revalidate, private" always;
        add_header Pragma "no-cache" always;
    }
}

Express.js (Node.js)

const express = require('express');
const app = express();

// Security headers middleware
app.use((req, res, next) => {
    // Content-Security-Policy
    res.setHeader('Content-Security-Policy',
        "default-src 'self'; " +
        "script-src 'self'; " +
        "style-src 'self' 'unsafe-inline'; " +
        "img-src 'self' data: https:; " +
        "font-src 'self'; " +
        "connect-src 'self'; " +
        "frame-ancestors 'none'; " +
        "base-uri 'self'; " +
        "form-action 'self'; " +
        "upgrade-insecure-requests"
    );

    // HSTS
    res.setHeader('Strict-Transport-Security',
        'max-age=63072000; includeSubDomains; preload');

    // Other security headers
    res.setHeader('X-Frame-Options', 'DENY');
    res.setHeader('X-Content-Type-Options', 'nosniff');
    res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin');
    res.setHeader('Permissions-Policy',
        'camera=(), microphone=(), geolocation=(), payment=(), usb=()');
    res.setHeader('X-XSS-Protection', '0');
    res.setHeader('Cross-Origin-Opener-Policy', 'same-origin');
    res.setHeader('Cross-Origin-Resource-Policy', 'same-origin');

    // Cache control for HTML responses
    if (req.path.endsWith('.html') || req.path === '/') {
        res.setHeader('Cache-Control',
            'no-store, no-cache, must-revalidate, private');
        res.setHeader('Pragma', 'no-cache');
    }

    next();
});

// Alternative: use the helmet package
// const helmet = require('helmet');
// app.use(helmet());

ASP.NET Core (Middleware)

// Add to Program.cs or create a custom middleware class
app.Use(async (context, next) =>
{
    var headers = context.Response.Headers;

    // Content-Security-Policy
    headers.Append("Content-Security-Policy",
        "default-src 'self'; " +
        "script-src 'self'; " +
        "style-src 'self' 'unsafe-inline'; " +
        "img-src 'self' data: https:; " +
        "font-src 'self'; " +
        "connect-src 'self'; " +
        "frame-ancestors 'none'; " +
        "base-uri 'self'; " +
        "form-action 'self'; " +
        "upgrade-insecure-requests");

    // HSTS (also configurable via app.UseHsts())
    headers.Append("Strict-Transport-Security",
        "max-age=63072000; includeSubDomains; preload");

    // Other security headers
    headers.Append("X-Frame-Options", "DENY");
    headers.Append("X-Content-Type-Options", "nosniff");
    headers.Append("Referrer-Policy", "strict-origin-when-cross-origin");
    headers.Append("Permissions-Policy",
        "camera=(), microphone=(), geolocation=(), payment=(), usb=()");
    headers.Append("X-XSS-Protection", "0");
    headers.Append("Cross-Origin-Opener-Policy", "same-origin");
    headers.Append("Cross-Origin-Resource-Policy", "same-origin");

    // Cache control for page responses
    if (context.Request.Path.Value?.EndsWith(".html") == true
        || context.Request.Path.Value == "/")
    {
        headers.Append("Cache-Control",
            "no-store, no-cache, must-revalidate, private");
        headers.Append("Pragma", "no-cache");
    }

    await next();
});

// Place BEFORE app.UseStaticFiles() and app.UseRouting()

Common Mistakes and Misconfigurations

Setting security headers incorrectly can be worse than not setting them at all. A misconfigured header gives a false sense of security while providing no actual protection — or, in some cases, actively breaking your application. These are the mistakes we see most frequently in the wild.

1. CSP with unsafe-inline and unsafe-eval

# This CSP provides almost zero protection against XSS
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'

Adding 'unsafe-inline' to script-src allows any inline <script> tag to execute, which is exactly how reflected and stored XSS payloads work. Adding 'unsafe-eval' allows eval(), Function(), and setTimeout(string), which are common XSS exploitation primitives. Together, they render CSP decorative. Use nonces ('nonce-{random}') or hashes ('sha256-{hash}') instead of 'unsafe-inline'.

2. HSTS with Short max-age

# 5 minutes of protection is effectively no protection
Strict-Transport-Security: max-age=300

A short max-age means the HSTS protection expires quickly. If an attacker can catch the user during a window when the HSTS policy has expired (or was never received), the SSL stripping attack succeeds. Use a minimum of one year (31,536,000 seconds), and ideally two years with preload.

3. Missing the always Parameter in Nginx

# Without 'always', headers are NOT sent on error responses
add_header X-Frame-Options "DENY";
# 404 and 500 pages will be missing security headers

# With 'always', headers are sent on ALL responses including errors
add_header X-Frame-Options "DENY" always;

4. Duplicate or Conflicting Headers

When both the reverse proxy (Nginx, Apache) and the application (Express, ASP.NET) set security headers, the result can be duplicate headers with conflicting values. Some browsers use the first value, some use the last, and some combine them. Decide on a single layer for header management and ensure the other layer does not add its own.

5. Forgetting frame-ancestors in CSP When Using X-Frame-Options

If you set CSP frame-ancestors 'none' and X-Frame-Options: SAMEORIGIN, the values conflict. CSP frame-ancestors takes precedence in browsers that support it, but older browsers will use X-Frame-Options. Ensure both headers express the same intent.

6. Referrer-Policy Set to no-referrer Breaks Analytics

Setting no-referrer sends zero referrer information on all requests, which breaks analytics platforms that depend on referrer data to attribute traffic sources. Use strict-origin-when-cross-origin to preserve the origin (domain) while stripping the path and query string.

Header Testing in CI/CD Pipelines

Security headers should not be a one-time configuration that you set and forget. They must be tested continuously, just like any other security control. Headers can regress when server configurations change, when new reverse proxy layers are added, when CDN settings are updated, or when application frameworks are upgraded. Embedding header checks into your CI/CD pipeline ensures that regressions are caught before they reach production.

Automated Header Checks with curl and Scripts

#!/bin/bash
# security-headers-check.sh - Run in CI/CD after deployment to staging

URL="https://staging.yourdomain.com"
FAILURES=0

check_header() {
    local header_name="$1"
    local expected_value="$2"

    actual=$(curl -sI "$URL" | grep -i "^$header_name:" | head -1)

    if [ -z "$actual" ]; then
        echo "FAIL: $header_name is MISSING"
        FAILURES=$((FAILURES + 1))
    elif [ -n "$expected_value" ]; then
        if echo "$actual" | grep -qi "$expected_value"; then
            echo "PASS: $header_name is present and correct"
        else
            echo "WARN: $header_name is present but value may be incorrect"
            echo "  Expected to contain: $expected_value"
            echo "  Actual: $actual"
        fi
    else
        echo "PASS: $header_name is present"
    fi
}

echo "=== Security Header Check: $URL ==="
check_header "Strict-Transport-Security" "max-age="
check_header "Content-Security-Policy" "default-src"
check_header "X-Frame-Options" "DENY"
check_header "X-Content-Type-Options" "nosniff"
check_header "Referrer-Policy" ""
check_header "Permissions-Policy" ""
check_header "Cross-Origin-Opener-Policy" ""
check_header "Cross-Origin-Resource-Policy" ""
check_header "X-XSS-Protection" "0"

echo ""
if [ $FAILURES -gt 0 ]; then
    echo "RESULT: $FAILURES header(s) missing - PIPELINE SHOULD FAIL"
    exit 1
else
    echo "RESULT: All security headers present"
    exit 0
fi

Integration with Popular CI/CD Platforms

# .github/workflows/security-headers.yml
name: Security Header Check
on:
  deployment_status:
    states: [success]

jobs:
  check-headers:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check Security Headers
        run: bash ./scripts/security-headers-check.sh
        env:
          URL: ${{ github.event.deployment_status.target_url }}

Monitoring Header Drift in Production

Beyond CI/CD checks, schedule periodic header scans against your production URLs. CDN configuration changes, certificate renewals, load balancer updates, and infrastructure-as-code drift can silently remove or alter security headers. A weekly automated scan that alerts on any missing header provides an essential safety net.

Compliance Requirements: Which Frameworks Require Which Headers

Security headers are not just best practices — they are increasingly explicit requirements in compliance frameworks. Auditors check for them. Penetration testers flag their absence. And regulatory bodies have begun referencing specific headers in their technical guidance documents. The table below maps each header to the compliance frameworks that require or recommend it.

PCI DSS 4.0 is the most prescriptive. Requirement 4.2.1 mandates strong cryptography for data in transit, which directly maps to HSTS. Requirement 6.2.4 requires that custom software is developed to prevent common vulnerabilities, including XSS (CSP), clickjacking (X-Frame-Options), and MIME confusion (X-Content-Type-Options).

HIPAA does not name specific headers, but its technical safeguards under 164.312 require encryption in transit (HSTS), access controls (X-Frame-Options, CSP), and audit controls that headers support indirectly. An auditor interpreting HIPAA's "reasonable and appropriate safeguards" will expect to see security headers on any web application handling PHI.

OWASP ASVS v4 (Application Security Verification Standard) is the most granular. Chapter 14 (Configuration) contains specific verification requirements for each security header, with exact expected values. If your organization uses ASVS as its application security benchmark, every header in this article is a testable requirement.

Beyond Headers: The Full ASPM Approach

Security headers are a critical first line of defense, but they are one layer in a comprehensive application security posture. Headers protect against client-side attacks by instructing the browser. They do not protect against server-side vulnerabilities like SQL injection, broken authentication, insecure deserialization, or business logic flaws. A complete security strategy requires visibility into the entire application attack surface.

What Security Headers Cannot Protect Against

• Server-side injection: SQL injection, command injection, LDAP injection, and template injection all execute on the server before any response headers are sent to the browser.
• Broken authentication: Weak passwords, missing MFA, session fixation, and credential stuffing attacks operate at the authentication layer, outside the scope of response headers.
• Vulnerable dependencies: Known CVEs in third-party libraries (Log4Shell, Spring4Shell, MOVEit) are exploited before your application code even runs. No header prevents this.
• API security: Broken object-level authorization, mass assignment, and excessive data exposure in APIs are business logic flaws that headers cannot address.
• Secrets exposure: Hardcoded API keys, database credentials, and private keys in source code or configuration files are not mitigated by any HTTP header.
• Infrastructure misconfiguration: Open S3 buckets, misconfigured IAM roles, exposed management ports, and default credentials on cloud services are infrastructure-layer issues.

Application Security Posture Management (ASPM)

ASPM is the discipline of continuously discovering, assessing, prioritizing, and remediating security risks across your entire application portfolio. It combines findings from multiple security testing methods into a unified view:

Security Factor 365 unifies all six testing methods into a single platform with a consolidated dashboard, deduplicated findings, AI-powered triage, and automated remediation guidance. Instead of managing separate tools for SAST, SCA, DAST, IaC scanning, secrets detection, and header checks, your security team gets a single pane of glass with correlated findings and a unified risk score for every application in your portfolio.

Conclusion: Security Headers Are Free Insurance

Security headers cost nothing to implement. They require no changes to your application logic. They take effect immediately for every user. And they defend against some of the most common and most damaging web attacks: cross-site scripting, clickjacking, protocol downgrade, MIME confusion, and data leakage.

Yet the majority of websites still ship responses without a complete set of security headers. The gap is not technical — it is awareness and process. Teams that check headers once, manually, during initial deployment inevitably see those headers regress over time as infrastructure changes, CDN configurations shift, and new reverse proxy layers are added.

The solution is automation. Scan your headers continuously. Test them in CI/CD. Alert on regressions. And treat a missing security header the same way you treat a failing unit test: as a build-breaking defect that must be fixed before deployment.