HTTP security headers: what to send, which values, and what breaks

02Which security headers should I send? The list with values

The table lists the headers worth sending, a value to start with, and what goes wrong when the value does not fit the site. Priority weighs how much each one protects a typical site against the risk of turning it on.

03In what order should I roll out security headers?

Start with the headers that cannot break anything, then add the ones that need a test period, letting each step run in production for a while.

• Step 1: X-Content-Type-Options and Referrer-Policy, after checking that scripts and stylesheets carry correct Content-Type values
• Step 2: frame-ancestors 'self' in a CSP header, which works before you write a full policy, plus X-Frame-Options: SAMEORIGIN
• Step 3: Permissions-Policy, switching off only features you know you do not use
• Step 4: Strict-Transport-Security, ramped up as hstspreload.org recommends: max-age=300, then 604800 (a week), then 2592000 (a month), each with includeSubDomains, before a long max-age; request preload last, because removal takes months
• Step 5: Content-Security-Policy-Report-Only for a few weeks, fix the reported sources, then send the same policy as Content-Security-Policy; both headers can run side by side
• Step 6: COOP, CORP and COEP where the site's popups and embeds allow them

04How do I add security headers in nginx without losing them?

Two nginx defaults catch almost everyone. Without the always parameter, add_header only applies to 200, 201, 204, 206, 301, 302, 303, 304, 307 and 308 responses, so error pages go out bare. And add_header directives are inherited only if the current level defines none of its own: in testing, a location with one add_header Cache-Control line returned none of the seven headers its server block set.

The reliable pattern is one include file, used at server level and again in every location that adds a header. nginx 1.29.3 added add_header_inherit merge to append the parent's headers instead; Debian 12's nginx 1.22 does not have it. The CSP line below restricts framing, plugins and base URLs only; it is not yet a script policy.

If the application behind the proxy sends one of these headers too, the browser receives both copies, and the HTML standard says two different X-Frame-Options values block framing entirely. Hide the application's copy with proxy_hide_header, or remove it in the application.

# /etc/nginx/snippets/security-headers.conf
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "frame-ancestors 'self'; object-src 'none'; base-uri 'self'" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;

# in the server block
server {
    # listen 443 ssl; server_name and certificates as usual
    include snippets/security-headers.conf;

    location /assets/ {
        include snippets/security-headers.conf;   # needed: this location adds its own header
        add_header Cache-Control "public, max-age=31536000, immutable";
    }

    location /app/ {
        proxy_pass http://127.0.0.1:9000;
        proxy_hide_header X-Frame-Options;          # the app sends its own value
    }
}

05How do I check which security headers a site sends?

Ask the server directly. The commands below make normal GET requests and print only the response headers. Check an error page and a static asset as well, because that is where the inheritance and always pitfalls show up: all three counts should match. In a browser, the Network panel of the developer tools shows the same headers per request.

# security headers on the home page
curl -s -o /dev/null -D - https://example.com/ \
  | grep -i -E '^(strict-transport|content-security|x-content-type|x-frame|referrer-policy|permissions-policy|cross-origin)'

# count them on a page, an error page and an asset: the numbers should match
for p in / /does-not-exist /assets/app.css; do
  printf '%s ' "$p"; curl -s -o /dev/null -D - "https://example.com$p" \
    | grep -i -c -E '^(strict-transport|content-security|x-content-type|x-frame|referrer-policy|permissions-policy|cross-origin)'
done

06What breaks most often, and how do I recognise it?

Header problems show up as features that silently stop working, and the browser console almost always names the header responsible.

07Can a CDN, WAF or reverse proxy set security headers for me?

Yes, and it is often the easiest place, because one rule covers every application behind it. A reverse proxy, CDN or WAF can add headers an application forgets, strip version-revealing ones such as X-Powered-By (which cuts scanner noise, not exposure, as the nginx 1.18.0 triage explains), and cover the error pages it generates itself. Adding a header at the edge while an application fix is pending is a form of virtual patching.

What the edge cannot do is write a good Content Security Policy for you, because a strict policy depends on nonces the application generates per response. Edge headers must also agree with the application's: browsers enforce every CSP header they receive and extra policies can only restrict further, so an edge policy stacked on the application's can block what neither meant to block.

08Which cookie settings and old headers belong in the same review?

A header review is the right moment to check cookies and remove headers that no longer do anything.

• Session cookies: Secure, HttpOnly and an explicit SameSite value, since only Chromium-based browsers treat a missing value as Lax; the __Host- prefix pins a cookie to one host
• Remove X-Powered-By and version numbers in the Server header, which tell attackers which known vulnerabilities to try
• Retire Expect-CT and Public-Key-Pins, which OWASP marks as not to be used, and replace Feature-Policy with Permissions-Policy
• Send Cache-Control: no-store on responses with personal data, so shared caches never keep them