Security headers communicate browser policies through an HTTP response. Their presence can reveal useful configuration decisions, but a list of header names is not a security assessment of the entire application. The right review asks which policy was returned, where it came from, how the browser uses it and whether it matches the website's real requirements.
Begin with a public page and a record of the expected application behavior. Does the page intentionally embed videos, load a payment provider or appear inside another trusted application? Those requirements matter when evaluating restrictive policies. A change that blocks a legitimate journey is not a successful repair simply because a previously missing header is now present.
Inspect the actual public response
Run the security headers checker against a production URL and retain the observed values. Compare another document and an error response where relevant. Hosting layers sometimes apply policies to normal pages but omit them from redirects or failures. A configuration file in the repository is not proof that the deployed response contains the same setting.
Use the HTTP response checklist to capture status and delivery context. If a CDN, reverse proxy and application can all add a header, identify which layer owns it. Duplicate or conflicting values require interpretation; adding another copy without understanding the existing chain can make the result harder to maintain.
Treat Content Security Policy as an application policy
A CSP needs to reflect the resources and behaviors an application legitimately requires. Inventory scripts, styles, fonts, frames and network destinations before designing a restriction. A copied policy from an unrelated brochure site may break an interactive application or leave unnecessary permissions in place. Review the actual dependencies rather than trusting a plugin's generic preset.
The MDN CSP guide explains browser enforcement and report-only deployment. A report-only policy can help observe prospective violations before enforcement, but its reports still require interpretation. Test important user journeys, distinguish expected dependencies from unexpected requests and keep a rollback procedure for the reviewed change. The scanner observes public policy evidence; it does not construct a complete dependency inventory for you.
Separate transport policy from certificate operation
HSTS concerns browser handling of HTTPS for a host. It is not a repair for an invalid certificate or a substitute for reliable HTTPS delivery. Confirm the affected host works over HTTPS before altering a long-lived transport policy. Evaluate any inclusion of subdomains deliberately rather than enabling it as an automatic score improvement.
The HTTPS audit article discusses the connection and hostname side of this work. If a proposed change extends beyond the host being tested, document the other services it affects. A public page scan cannot establish the operational readiness of every subdomain, certificate renewal process or independent application owned by the organization.
Review framing and browser-feature requirements
Framing restrictions should match whether the page is supposed to be embedded. A management screen may have a very different requirement from a public widget. Ask the product owner which embedding relationships are supported before choosing a policy. Test both an allowed legitimate use and an intentionally disallowed example in a controlled environment when making a configuration change.
Permissions-related policy also needs application context. A page using a browser capability may behave differently from a static article that has no such requirement. Do not enable features universally because a template includes them, or disable every feature without testing the application. Record the reason for each meaningful policy decision alongside the responsible configuration source.
Check content interpretation and referral behavior
Review response content types together with content-sniffing controls. The intended file format and the browser's interpretation should agree. An upload endpoint, a stylesheet and an HTML document are different resources, so inspect the actual responses rather than applying a single assumption to all paths. If a resource is delivered incorrectly, investigate both the policy and the underlying content-type configuration.
Referral policy affects information sent when navigating or requesting resources. Consider the site's real links, analytics requirements and privacy expectations before changing it. Test an actual cross-origin journey if the application depends on referral information. A scanner can report a value, but it does not know which external service relationships the site owner has intentionally established.
Change one responsible layer and verify behavior
Prepare the proposed configuration in a reviewable change and test it on representative pages. Include the homepage, a detail template and any interaction involving external resources. Watch browser errors and relevant application behavior. If a change belongs at the hosting layer, coordinate that ownership rather than adding a competing application-level setting to work around it.
After deployment, request the same URLs again and compare the complete values, not merely whether the names exist. Keep before-and-after evidence and document any expected remaining exceptions. The scan comparison workflow helps organize this check. Retest when dependencies, embedding requirements or deployment infrastructure change.
Know when a public header review is insufficient
Header observations do not prove that authorization, session management, input handling or data storage are secure. They also do not establish that a website is compromised when a particular policy is absent. Describe the result as a public configuration review and direct deeper questions to an appropriately scoped, authorized assessment.
Use the report to make a justified configuration decision with a named owner and a test plan. That is more valuable than enabling a collection of policies without understanding their operational effects. A sound security-header review improves clarity about browser behavior while keeping its evidence and its limitations explicit.
Compare different security review questions
| Approach | Evidence | Useful for |
|---|---|---|
| Header inspection | Public response policy values | Checking browser-policy configuration |
| Browser journey test | Whether required resources and interactions still work | Validating a reviewed policy change |
| Authorized security assessment | A separately defined application-security scope | Questions a public header report cannot establish |
Using CrawlNFix for this task
CrawlNFix provides a free public header review without requesting administrator credentials, a paid account or a provider API key. Run it online against the intended public response and keep the evidence for the responsible operator. A saved report can be read offline, but offline reading does not remeasure current server policies. Apply configuration changes through your own authorized maintenance process and verify the production response afterward.