A homepage can return an impressive set of security headers while a password-reset page, an error response or a cached download returns a different policy. The deployment unit is the delivered response, not the configuration file where a header was first added. An audit should therefore follow representative routes through the application and its delivery layers.
Use a small fictional customer portal as the working example. It has a public homepage, a sign-in form, an authenticated account area, an API and a CDN. The goal is to identify which component supplies each policy and verify that important user journeys still work. This approach is useful after a proxy migration, framework update or new CDN rule, when apparently unrelated response classes can change.
Choose response classes before collecting headers
Start with routes that exercise different application paths. Include an ordinary successful page, the initial HTTP-to-HTTPS redirect, an unauthenticated protected route, a missing page and a representative static asset. Add an authenticated response in a controlled browser session if that is part of the service. Do not send session credentials to an unrelated public checker.
Methods matter. A command that sends HEAD can receive a different response from the GET used by the browser, particularly when middleware or caches handle methods separately. Record the method, final URL and status for every observation. If redirects occur, preserve the chain rather than keeping only the last response.
The HTTP header inspector observes a public response from the site server’s network position. It can help establish a baseline for public routes. It cannot reproduce your authenticated browser session, every edge location or a workflow that depends on scripts and cookies.
Build a response matrix with an explicit expectation
| Response | Expected role | Evidence to inspect |
|---|---|---|
| HTTP homepage redirect | Send navigation to the intended HTTPS hostname | Status, Location and accidental downgrade or host changes |
| HTTPS homepage | Deliver a public document | HSTS, document policy, content type and framing rules |
| Sign-in page | Create an authenticated workflow | CSP compatibility and cookie attributes when a session begins |
| Account page | Return private application data | Policy, caching behaviour and authenticated response differences |
| Missing route | Return a controlled error document | Status and whether the error handler preserves intended policy |
| Static script | Supply executable content with the right type | Content-Type, nosniff and cache behaviour |
The matrix is not a demand that every header appear identically on every resource. A document’s CSP has a different role from the metadata on a downloadable file. Decide what each response is supposed to do, then judge its delivered policy against that role. Otherwise, an audit can reward irrelevant headers and miss the control that actually protects the workflow.
Find the layer responsible for each policy
A response may pass through application middleware, a web server, a reverse proxy and a CDN. Each layer can add, replace or duplicate headers. Record ownership so a future change has a clear destination. If the application sets one CSP and the edge adds another, treating the second as a simple override can be a serious mistake.
Multiple enforcing CSP policies are applied together; a permissive policy does not necessarily cancel a restrictive one. Other headers have their own parsing and combination rules. Do not assume that a comma-joined display in a developer tool means the browser interprets every header as a harmless list. Inspect the actual header instances when troubleshooting duplicate policy.
Centralising a policy at an edge can provide broad coverage, but it also means the policy owner must understand application exceptions. Application-generated nonces, for example, need coordination with the document body. An edge rule that inserts a nonce-looking string without matching the allowed script attributes does not create a working nonce policy.
Diagnose a policy that disappears on errors
Suppose the homepage and account page return a framing restriction, while the custom 404 page does not. The missing route may be handled by a different application branch or by the reverse proxy itself. Compare response headers and page content to identify the component producing the error.
Check whether the relevant configuration applies only to successful responses. Some web-server directives distinguish normal response handling from rules that also apply to errors. Make the correction in the component that actually serves the error class. Adding the same header to an unrelated application controller will not affect a proxy-generated page.
After the change, repeat the missing-route request and a normal successful request. Then exercise an expected authentication failure and a controlled application error in an appropriate test environment. The objective is to verify coverage without creating a new conflict or exposing internal error details. Keep this response matrix as a regression record for later infrastructure changes.
Treat HSTS and redirects as separate controls
An HTTP redirect moves a request after the server receives it. HSTS tells a supporting browser to use HTTPS for future covered requests after learning a valid policy, or through a preload arrangement. The presence of a redirect therefore does not establish the same behaviour as an effective HSTS policy.
Inspect the secure response’s max-age and any includeSubDomains directive. A broad subdomain commitment requires an inventory of services, including delegated and third-party-hosted names. The HSTS analyser can interpret pasted policy text, but it cannot prove that every subdomain is ready for HTTPS.
Keep preload decisions out of a quick header-score cleanup. Browser distribution and removal timelines make them operational commitments. If the immediate task is to repair a missing policy, establish the hostname’s HTTPS reliability and a deliberate rollout plan before expanding coverage.
Verify the browser workflow, not just the header text
A CSP can be syntactically plausible and still block checkout, sign-in or a required connection. Use the browser console and network panel to identify the actual blocked resource or operation. Report-only deployment can help collect evidence before enforcement, but it observes rather than blocks and requires a working reporting destination to collect reports remotely.
Run both successful and failed user journeys. A login success page may load a different script from the initial form. A payment return can arrive through a cross-site navigation that exposes a cookie attribute problem. An embedded support widget can depend on framing or connection permissions that the homepage alone never exercises.
When a flow fails, change the narrowest relevant rule after understanding the dependency. Adding wildcards everywhere may silence a violation while discarding the reason for the policy. If a third-party script is the source of broad permission requirements, evaluate the dependency itself rather than treating its entire requested access as automatically necessary.
Check cached and uncached delivery deliberately
An edge can continue serving a cached response with earlier headers after the origin configuration changes. Compare cache-related evidence and the deployment timeline. A cache bypass can help inspect an origin path, but it should not be mistaken for what ordinary visitors receive through the normal delivery route.
Recheck representative responses after the expected cache transition. If only one location or route behaves differently, preserve that distinction. Avoid asserting that a policy is globally deployed from one successful request. The useful completion record states which routes and delivery conditions were tested and which remain outside the audit.
Frequently asked questions
Can a service worker affect what I am inspecting?
Yes. A browser-controlled application can receive a response through a service worker or local cache rather than the network path you intended to test. Developer tools can help distinguish those sources. Keep a normal-user observation and a controlled network observation separate; bypassing application behaviour is useful for diagnosis but does not describe every visitor’s experience.
Should a redirect and its destination be recorded separately?
Yes. The redirect supplies its own status and Location, while the destination supplies the final document. A redirect can change hostnames, schemes or paths before the final response is inspected. Recording both helps explain certificate errors, unexpected origins and policy differences that disappear when a checker shows only the last response.
Should every response contain the same security headers?
No. Requirements depend on the response’s role, content type and application behaviour. Consistency is useful where a policy is intended to apply broadly, but copying a document policy onto every asset is not a substitute for deciding which controls are relevant.
Does a missing header prove the site is vulnerable?
It establishes that the observed response lacks that header, subject to the test’s scope. Whether this creates an exploitable problem depends on application behaviour and other controls. Describe the missing defence and affected workflow rather than inventing an exploit from absence alone.
Why does a public checker disagree with my browser?
The requests may use different methods, sessions, locations, paths or cache states. Your browser can also follow a different redirect chain. Compare those conditions before deciding that either result is wrong. Authenticated pages should be reviewed in an appropriately controlled session.
What belongs in the audit handoff?
Include the response matrix, policy owner, exact changed configuration, deployment time, observed headers and tested user journeys. Record remaining exceptions and their reasons. That evidence makes a later regression easier to diagnose than a screenshot of a single overall score.