Verify security headers across real response paths
Build a route and response matrix for browser headers. Check edge delivery, errors, downloads, and policy meaning rather than counting header names.
A security-header review needs representative responses, not one request to the homepage. An application can emit correct headers on a successful page while losing them on an authentication error, file download, or edge-generated response. Define the response classes and the protection each one needs.
OWASP's HTTP header guidance explains the distinct roles of content type, framing, transport, referrer, and cache policies. Treat this as a policy review rather than a score based on the number of headers present.
Build the response matrix
Inspect delivered headers through the same proxy and CDN path users receive. Record redirect responses and final responses separately. An application configuration file is useful context but is not evidence of what reached the browser.
| Response class | Relevant decision | Check to retain |
|---|---|---|
| Public HTML | Script and framing policy | Effective CSP and required frame behavior |
| Authenticated HTML | Private data and navigation | Cache and referrer decisions |
| User download | Type and presentation | Correct media type and disposition |
| Error response | Same protected boundary | Headers survive the failure path |
| HTTPS host | Transport policy | Intended HSTS scope and readiness |
Avoid enabling broad transport-policy scope until the covered hosts support it. A copied header can create an outage when its implications have not been checked.
Verify behavior where a header matters
For a framing policy, use a controlled parent page. For CSP, exercise representative scripts and connections. For caching, inspect reuse with synthetic identities. A header string can be syntactically present yet inconsistent with the intended behavior.
Check for duplicate or conflicting headers introduced by different layers. Record which layer owns the final value. Include non-success responses and files served directly by object storage if they remain part of the user journey.
Keep the review tied to a release
Save route, method, status, delivered header values, build, and observation time. Redact cookies and other secrets from captures. Add focused automated assertions for stable policies, while retaining browser checks for behavior that a response-only test cannot establish.
Recheck the matrix after changing hosting, redirects, authentication middleware, or download serving. Do not add obsolete headers solely to satisfy an old checklist. Completion means the relevant response classes deliver and enforce the selected policies, with documented exceptions and owners. It does not mean the application is secure merely because a header inspection reports no omissions.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.
Sources
- OWASP HTTP Headers Cheat SheetAccessed