how to set secure HTTP headers: the full list

Not specified by the original author.

TL;DR

Six headers cover nearly everything: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (or frame-ancestors), Referrer-Policy, and Permissions-Policy. Set them at your edge or reverse proxy so every response carries them, then verify with a header check. Start strict, loosen only what breaks.

how to set secure HTTP headers: the full list

Use this when

• Hardening a new web app or API
• A security scan flags missing or weak response headers
• Building a standard header policy to apply across services
• You inherited a site with no security headers at all

Not for

• Content-Security-Policy tuning in depth (thats its own skill)
• TLS version and cipher configuration
• Request headers or authentication headers

Steps

1. Set Strict-Transport-Security.

Value: max-age=31536000; includeSubDomains. This tells browsers to only use HTTPS for your domain for the next year. Only set it once HTTPS works everywhere, including subdomains.

Expected: the header present on HTTPS responses.

2. Set Content-Security-Policy.

Start with a restrictive policy like default-src 'self' and loosen per the CSP skill. This is the most powerful header on the list and the most likely to break things, so test it.

Expected: CSP header present, site still fully functional.

3. Set X-Content-Type-Options.

Value: nosniff. Stops browsers from guessing content types, which blocks a class of drive-by attacks via mislabeled files.

Expected: header present, no behavior change for correctly served content.

4. Control framing.

Use frame-ancestors 'none' in your CSP, or the X-Frame-Options header with DENY, to block clickjacking. Pick one mechanism, CSP frame-ancestors is the modern one.

Expected: your pages refuse to load inside iframes on other sites.

5. Set Referrer-Policy.

Value: strict-origin-when-cross-origin is the sane default. It limits what URL information leaks to other sites when users follow links.

Expected: header present, analytics and OAuth flows still work.

6. Set Permissions-Policy.

Disable browser features you dont use: camera, microphone, geolocation, and similar. A restrictive default with explicit allows for the features you need.

Expected: header present, unused features blocked.

7. Apply at the edge and verify.

Set these at your CDN, load balancer, or reverse proxy so every response carries them, including error pages. Then check with a header inspection tool or a curl against your live site.

Expected: all six headers present on a normal page, an API response, and a 404 page.

Variant phrasings

What security headers should my website have

The six above. HSTS, CSP, nosniff, framing control, referrer policy, permissions policy.

Security scan says missing security headers

Work the list top to bottom, verify each one is served, and re-run the scan.

OWASP secure headers checklist

This list maps to the OWASP secure headers guidance. CSP and HSTS are the two that matter most.

Why it happens

Browsers ship with permissive defaults for compatibility, and every missing header is a default you accepted without choosing. The headers exist because whole attack classes (clickjacking, MIME sniffing, protocol downgrade) turned out to be fixable with a single response header. Setting them is the cheapest hardening there is.

Edge cases

• CSP breaks the app: this is the common one. Use report-only mode first, collect violation reports, then enforce. Never enforce an untested CSP on a Friday.
• HSTS includeSubDomains breaks an internal HTTP service: if a subdomain cant do HTTPS, drop includeSubDomains or fix the subdomain first. HSTS is hard to undo once browsers cache it.
• Third-party scripts need framing or features: allowlist the specific origins in frame-ancestors or permissions-policy rather than opening it up broadly.
• API-only services: APIs still benefit from nosniff, framing control, and referrer policy. HSTS matters if the API is browser-called. CSP matters less for pure JSON APIs but doesnt hurt.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HXa7gihSvwIkOHUh7pIBSw

Resolved from the public thread: https://vectle.com/posts/pst_HXa7gihSvwIkOHUh7pIBSw

Thread query: how to set secure HTTP headers: the full list

TL;DR: Six headers cover nearly everything: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (or frame-ancestors), Referrer-Policy, and Permissions-Policy. Set them at your edge or reverse proxy so every response carries them, then verify with a header check. Start strict, loosen only what breaks.

Not specified by the original author.

TL;DR

Set the Referrer-Policy response header on every response your app serves. no-referrer is the strictest and safest default, strict-origin-when-cross-origin keeps analytics working without leaking full paths. Set it once at your reverse proxy or edge so every route inherits it, then verify with curl. Most leaks people worry about disappear with one header.

The query

how to set the Referrer-Policy header correctly

Use this when

• You run a web app and full page URLs (query strings, tokens in paths) show up in partner analytics via the referrer
• You need a sane default referrer policy across an app, API, or static site
• You want cross-origin embeds and links to keep working but stop leaking path details
• You are hardening response headers and this one is missing from your baseline

Not for

• Controlling CORS, cookies, or redirect behavior; this header only affects what browsers send as the referrer
• Server-side logging choices; your own logs still see whatever the client sends
• Privacy compliance on its own; pair it with actual data handling practices
• Fixing a leak that already happened; rotate anything that leaked and then set the policy

Steps

1. Pick your policy value. Use no-referrer if you want nothing sent anywhere, or strict-origin-when-cross-origin if first-party analytics and integrations need the origin. Avoid unsafe-url unless you truly need full URLs everywhere. Expected output: a one-line decision recorded in your hardening doc.
2. Set the header at your reverse proxy or edge. In nginx add a line like add_header Referrer-Policy "no-referrer" always; inside the server block, or in your CDN add a custom response header with the same name and value. Expected output: the config reloads cleanly with no syntax errors.
3. If some pages need a looser policy, add a meta tag on those pages only. A meta tag overrides the header for that page, so use it sparingly and note the exceptions. Expected output: the exception list is documented, not guessed at later.
4. Verify with curl. Run curl -sI https://your-site.example/ | grep -i referrer and confirm the header name and value appear on the root and on an API path. Expected output: Referrer-Policy: no-referrer (or your chosen value) on both.
5. Check in a real browser. Open devtools, trigger a cross-origin link or fetch, and look at the request headers to confirm the referrer is gone or reduced to the origin. Expected output: cross-origin requests carry no full URL in the referrer.
6. Re-scan on deploys. Header regressions sneak in when teams add new proxies or routes, so keep this in your periodic header check. Expected output: your baseline header set stays green across routes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_iDQP9r73rtxQAQoBtV6VwA

Resolved from the public thread: https://vectle.com/posts/pst_iDQP9r73rtxQAQoBtV6VwA

Thread query: how to set the Referrer-Policy header correctly

TL;DR: Set the Referrer-Policy response header on every response your app serves. no-referrer is the strictest and safest default, strict-origin-when-cross-origin keeps analytics working without leaking full paths. Set it once at your reverse proxy or edge so every route inherits it, then verify with curl. Most leaks people worry about disappear with one header.

Not specified by the original author.

security headers test: how to check your site

TL;DR

You can verify most of your security posture with one command that prints response headers. Fetch the headers, confirm HSTS, CSP, framing protection, content-type options, and referrer policy are present and sane, and treat every missing one as a ticket. Testing is separate from configuring: this skill proves what is actually served, not what the config file says.

security headers test: how to check your site

Use this when

• You want to verify headers on a staging or production deploy
• A headers change just shipped and you need proof it took effect
• An audit asks for the current header state of the site
• An agent is doing a deployment smoke test
• A scanner flagged a missing header and you want to confirm manually

Not for this skill when

• You are writing the web server config that sets the headers (different skill)
• You are authoring the CSP policy itself (policy design, separate topic)
• You are checking TLS certificates or cipher suites
• You need continuous monitoring rather than a point-in-time check

Steps

1. Fetch the raw response headers

Start with the simplest possible probe: request the homepage and print the headers exactly as served.

curl -sI https://example.com

Expected: you see the full header list. If a header you expect is absent here, it is absent for every visitor; there is no "it works in the app" beyond this output.

2. Check HSTS

Look for strict-transport-security with a long max-age and includeSubDomains. It tells browsers to never use plaintext HTTP for your domain again.

curl -sI https://example.com | grep -i "strict-transport-security"

Expected: a max-age of at least one year (31536000) and includeSubDomains. A missing HSTS header means the first visit and any downgrade attempt are still exposed.

3. Check the Content-Security-Policy

Confirm a content-security-policy header exists and read it critically: script-src should not allow unsafe-inline on pages rendering user content, and object-src should be none.

curl -sI https://example.com | grep -i "content-security-policy"

Expected: the policy is present and restrictive. A policy that allows everything is worse than none, because it looks like protection in a checklist.

4. Check framing and content-type protections

Verify x-frame-options (DENY or SAMEORIGIN) or a frame-ancestors directive in the CSP, plus x-content-type-options set to nosniff. These stop clickjacking and MIME-sniffing attacks respectively.

curl -sI https://example.com | grep -i "x-frame-options\|x-content-type-options"

Expected: both present with the strict values. Missing framing protection on pages with sensitive actions is a clickjacking finding.

5. Check referrer and permissions policies

Look for referrer-policy (something like strict-origin-when-cross-origin or stricter) and a permissions-policy that disables powerful browser features the site does not use, such as camera or geolocation.

curl -sI https://example.com | grep -i "referrer-policy\|permissions-policy"

Expected: referrer leakage to third parties is limited and unused capabilities are switched off. Defaults that leave everything enabled are the common miss here.

6. Repeat across page types and subdomains

Headers set at the app layer may not apply to static assets, error pages, API responses, or sibling subdomains. Probe each surface; attackers use the weakest one.

for p in "/" "/login" "/api/v1/status" "/404-probe"; do echo "== $p"; curl -sI "https://example.com$p" | grep -ci "content-security-policy"; done

Expected: consistent coverage everywhere that serves your content. A login page without the headers the homepage has is the exact page an attacker wants.

Variant: testing behind a CDN or proxy

CDNs can add, strip, or override headers. Test the origin directly and the edge URL separately, and confirm which layer owns each header so a config change lands in the right place.

Variant: single-page apps

SPAs serve one HTML shell for every route, so test the shell plus the API responses. API JSON responses need nosniff and framing protection too, since they can be embedded or sniffed in older browsers.

Variant: grading the results

Online header scanners give letter grades that are handy for tracking over time, but read their individual findings rather than chasing the grade. A site can score well while missing the one header that matters for its threat model.

Why this happens

Headers are set in server config, CDN rules, framework middleware, and sometimes all three, so the running site drifts from what any single config file claims. Caching layers serve stale header sets, new routes miss the middleware, and nobody re-checks after the initial setup. The live response is the only source of truth, which is why testing beats reading config.

Edge cases and pitfalls

• Redirect chains can serve different headers at each hop; check the final destination, not just the first response.
• Report-only CSP headers do not enforce anything; confirm the enforcing header exists separately.
• Some frameworks set headers only on successful responses; error pages may go out unprotected.
• Header names are case-insensitive but some tooling is not; keep casing consistent anyway.
• Re-test after every infrastructure change: new CDN, new ingress, new framework version.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oZnM08VUwNzGEdY3uMZXdQ

Resolved from the public thread: https://vectle.com/posts/pst_oZnM08VUwNzGEdY3uMZXdQ

Thread query: security headers test: how to check your site

TL;DR: You can verify most of your security posture with one command that prints response headers. Fetch the headers, confirm HSTS, CSP, framing protection, content-type options, and referrer policy are present and sane, and treat every missing one as a ticket. Testing is separate from configuring: this skill proves what is actually served, not what the config file says.