Security Headers

Review deployed headers as a release artifact, not just a config file.

The root `_headers` file is only useful when the hosting platform applies it correctly. Use this page to check intent, deployment, and follow-up risk.

Open _headersCSP ChecklistStatic Health

Verify

Deployedcheck actual response headers on the public domain

Protect

Staticpublic text files, manifest, sitemap, and well-known routes need review

Stage

CSPtest report-only or staging before enforcing new policy

Record

Changeheader changes belong in release notes and QA checks

Review Checklist

What to inspect before shipping header changes

Compare file to deployment

Open `_headers`, then inspect response headers on Home, one page under `/pages/`, public text files, sitemap, manifest, and `/.well-known/security.txt`.

Confirm baseline protections

Review expectations for content type, frame embedding, referrer behavior, permissions policy, and whether static assets inherit the right defaults.

Check public indexing files

Confirm `robots.txt`, `sitemap.xml`, `llms.txt`, `humans.txt`, and `site.webmanifest` still load after header or routing changes.

Do CSP separately

Content Security Policy changes should be tested through the CSP staging checklist before enforcement, because module and tool behavior can break quietly.

Keep cache changes intentional

If cache headers change, check generated assets, route data, search index, sitemap, and tool runtime query keys so users are not stuck on stale behavior.

Document the decision

Record what changed, what was verified, and what still needs deployed-domain inspection in release notes or QA notes.

Copyable Examples

Starter headers to adapt and test on the deployed site

CSP Checklist

Basic baseline

Low-risk browser protections

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: DENY
Permissions-Policy: camera=(), microphone=(), geolocation=()

Example only. Test actual response headers after deployment; hosting platforms differ.

CSP starter

Begin with report-only thinking

Content-Security-Policy: default-src 'self'; img-src 'self' data:; script-src 'self'; style-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Example only. CSP can break scripts, styles, images, embeds, analytics, or tool behavior. Stage and test before enforcing.

Header review note

Copy QA evidence

Security header review:
Route checked: [home/page/static file]
Expected header source: [_headers / platform config]
Observed response headers: [paste summary]
CSP staged/tested: [yes/no/not applicable]
Regression risk: [JavaScript/styles/assets/embed/cache]
Follow-up: [owner, deadline, deployed-domain check]