Direct answer
Security header testing checks whether HTTP responses deliver useful browser protections for the application. Review actual policies on HTML, authenticated responses, errors, and redirects, then connect any gap to its relevant behavior rather than relying on a single score.
Check representative response types
The homepage may be served by a different layer from the account dashboard or API. Record headers on a public page, a signed-in page, an error response, and any relevant redirect. Compare the final response with gateway and application configuration.
- Keep the full redirect chain in your assessment notes.
- Identify which responses contain sensitive data or active HTML.
- Repeat checks on the canonical origin used by customers.
Assess protection and compatibility
HSTS affects HTTPS use, frame restrictions affect embedding, and nosniff affects MIME interpretation. Different response types need different protections. Avoid adding obsolete headers solely to improve a score, and review subdomain readiness before broad transport policies.
Reference: OWASP HTTP Headers Cheat Sheet.
Prioritize the exposed behavior
A missing frame restriction on a page with sensitive actions is different from its absence on an image. State which browser behavior remains possible and whether another policy already covers it. Separate a configuration recommendation from a demonstrated attack path.
- Review content type and cache behavior on account exports.
- Check intended iframe integrations before restricting embedding.
- Document the route and response type for each recommendation.
Retest legitimate application journeys
A policy change can affect checkout, identity providers, previews, or embedded dashboards. Verify the intended browser journeys after deployment and recheck the response headers that customers actually receive. Keep a rollback plan for policies that can make a site inaccessible.
Assessment limits
Headers are one protection layer. They do not establish secure server-side permissions, query construction, or business logic. A homepage-only check cannot describe every application route, and a numerical grade is not a vulnerability assessment.
Frequently asked questions
Do perfect header scores prove a site is secure?
No. Header checks cover a narrow set of browser and response protections. Authentication, authorization, input handling, and workflows need separate assessment.
Should APIs have the same headers as HTML pages?
Evaluate the response's use. A JSON API and an interactive HTML page have different browser behavior, although both may need appropriate content types and sensitive-data cache controls.
Why can a header fix break the site?
Policies can restrict scripts, frames, network calls, or transport behavior used by legitimate features. Test those features and the deployed headers together.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.