Review the response you actually captured

Security headers are response metadata interpreted by browsers or other clients. MDN's HTTP header reference documents the fields discussed here. A pasted list can show which header names and values appeared in one capture, but it does not tell you whether the capture came from the right route, status code, redirect hop, content type, or deployment. Start with the exact response boundary and note the scheme, host, path, status, and date. Compare the same request after any proxy or CDN that can rewrite headers.

A header checklist is a prompt for investigation, not a grade. The policy needs to match the application’s resources, navigation, embedding, and compatibility requirements. A stricter value can break legitimate pages; a permissive value can leave a gap. Test changes in a representative environment and inspect browser behavior before treating a configuration as complete.

Content Security Policy needs a resource inventory

Content Security Policy (CSP) lets a site control which sources the browser may use for categories of resources, and it has directives for other behavior. MDN's CSP guidance recommends testing a policy in report-only mode before enforcing it. The policy's value comes from constraining the actual page, so a generic string copied from a checklist is not a substitute for knowing how the site loads scripts, styles, images, frames, workers, and connections. Begin with a report-only policy or another safe observation process when the deployment supports it, then review violations and tune the policy deliberately.

Avoid casually adding broad allowances to silence a violation. If a page uses inline scripts, third-party embeds, or dynamically loaded resources, decide how each is authorized and what breaks when the source is blocked. The header review tool can tell you that it did not see an enforced CSP field in the pasted text. It cannot parse the full policy, inspect the DOM, evaluate a report-only header, or prove that a policy is effective.

Apply HSTS only with domain and deployment context

HTTP Strict Transport Security (HSTS) tells a browser to use HTTPS for a host after it has received the policy over a secure connection. MDN documents the max-age and includeSubDomains behavior. The max-age value controls how long that instruction is retained. The includeSubDomains directive affects subdomains as well, and preload programs have additional operational expectations. These choices can affect services that are not part of the page under review.

Check that HTTPS works consistently before enabling a long duration. Inventory relevant subdomains, redirects, certificate deployment, and any legacy endpoints. A header copied from an HTTP response is not the same evidence as the browser accepting HSTS from HTTPS. Benchlight flags HSTS as contextual when absent; it does not know whether the supplied host is secure or whether subdomains are ready.

Check framing through the policy that is actually used

X-Frame-Options and the CSP frame-ancestors directive are related ways to restrict whether other pages can embed a response in a frame. MDN's X-Frame-Options reference documents the header's framing role. Review the response used for the sensitive page and consider legitimate embedding requirements. A broad header rule may affect login flows, partner integrations, or internal tools. A CSP can express other resource restrictions too, so do not replace a full policy with only a frame directive.

When investigating a framing issue, reproduce it with the real parent and child origins in a controlled test. Check redirects, because a final page can have different headers from the initial response. A static header scan can notice the presence of a familiar directive but cannot determine whether the browser applied it or whether the policy matches every route.

Treat CORS as an access decision, not a blanket hardening switch

Cross-Origin Resource Sharing (CORS) controls whether browser JavaScript from one origin can read a response under the browser's same-origin model. MDN's CORS guide documents the origin and credential rules. It is not a substitute for server-side authorization. Review the allowed origin, methods, headers, credentials behavior, and preflight response against the routes that need cross-origin access.

A wildcard origin cannot be used to satisfy a credentialed browser request whose credentials mode is included. If an application needs credentials, it generally needs an explicit permitted origin and a response that varies appropriately when that origin is selected. A pasted pair of Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true is therefore a signal to check the intended configuration; the pair alone does not tell you which browser request was made or whether credentials were included.

Add context for smaller controls

MDN's X-Content-Type-Options reference describes how nosniff affects certain MIME-type sniffing behavior, but the server still needs to send correct content types. Referrer-Policy controls how much referrer information is included in requests and should be chosen with the product's navigation and privacy needs in mind. Neither field is meaningful as an isolated checkbox. Inspect the actual value and consider how links, scripts, downloads, and embedded resources behave.

Headers can also be duplicated or combined by servers, proxies, or deployment layers. A simple line parser may merge repeated names for display but does not implement every HTTP field's list grammar. Capture the actual response with an approved tool and inspect how the browser sees it. Do not infer the final effective value from one configuration file if a gateway can add another header.

Review one header block without inventing a security grade

Paste this fictional response block into Header Review:

HTTP/1.1 200 OK
Content-Security-Policy-Report-Only: default-src 'self'
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

The checklist reports that no enforced Content-Security-Policy was found. That is consistent with the input: the report-only header observes policy violations without enforcing the policy. It also highlights the wildcard origin alongside credentials, missing HSTS context, and missing frame protection. There is no nosniff or Referrer-Policy omission in this fixture. Counting only missing names would miss the distinction between a configured header and an effective browser policy.

Investigate the CORS question first by establishing whether browser requests actually include credentials. For a credentialed cross-origin request, a wildcard allowed origin does not permit the browser to expose the response. Replacing it with an explicit permitted origin requires a genuine allow-list decision. If an application varies that response by requesting origin, its cache behavior also needs review; the local paste does not exercise a proxy or shared cache.

Next decide whether the page is meant to be framed. An enforced policy containing only default-src 'self' does not define frame-ancestors: that directive has no default-src fallback. If embedding must be restricted, choose the intended ancestors and test that restriction on the actual response. Do not add a policy merely to make the checklist shorter.

Finally, evaluate HSTS only for a suitable HTTPS hostname with a functioning certificate and an understood subdomain inventory. The absence shown here is a question about deployment. It cannot be resolved from this fictional block or from a successful local HTTP preview. The useful handoff is a list of these concrete configuration decisions, with the owning route and browser request attached.