HTTP security headers: what to check first

Start with the final response

Scan a public page on its normal HTTPS URL. HeaderScan follows up to five redirects and examines the final response. If the scan ends on a login screen, access-denied page or CDN challenge, its headers describe that response. They do not establish which policies your application sends on other pages.

Compare a content page, a form and an error page when reviewing your own site. Put shared policy in the layer that owns those responses, and check whether a proxy adds a second value. Changing an application setting is only useful if the intended header reaches the browser.

Make Content Security Policy fit your page

Content-Security-Policy limits resources a page can load. A policy that allows every script origin offers little protection. A policy that excludes a required payment or sign-in script can break the page. Inventory the resources you need before deciding which sources to allow.

Use Content-Security-Policy-Report-Only during a staged rollout to observe violations without enforcing that policy. Test important flows in a browser and review the findings before enforcing it. HeaderScan inspects headers; it does not execute scripts or prove that a policy is compatible with your application.

Reference: MDN: Content-Security-Policy

Check HTTPS and framing rules separately

Strict-Transport-Security tells browsers to use HTTPS for future requests to a host for a specified period. Only enable includeSubDomains after checking that the affected subdomains can serve HTTPS reliably. A long policy is a commitment to keeping those endpoints working.

Framing policy answers a different question: which sites may embed your page? CSP frame-ancestors can restrict embedding. Decide whether your product needs to appear in a partner iframe before choosing a policy. The presence of a header alone does not show that its value matches that requirement.

Reference: MDN: Strict-Transport-Security

Verify one policy change at a time

Keep a short record of the affected URL, the finding and the intended browser behavior. This gives you something more useful to verify than a higher score.

1. Choose one finding and identify whether the application, web server or CDN supplies the header.
2. Apply the policy in a test environment and exercise forms, login and embedded content.
3. Deploy, scan the same public URL again and inspect the actual value returned.
4. Review other response types before treating the change as a site-wide fix.