HTTP security headers tell browsers how to handle parts of a site's behavior. They can reduce exposure to particular risks, but their meaning depends on the policy value and the application. “Header present” is a useful observation, not a complete security verdict.
Start with the response you actually received
Inspect the final document response in browser developer tools. Record the URL, redirects, status, and header values. Check more than the homepage when application routes, error pages, or a CDN may return different policies.
A TLS certificate, an HTTP-to-HTTPS redirect, and mixed content are related checks, but they are not themselves response headers. Keep those findings separate when creating a repair plan.
Understand the main controls
Content-Security-Policy (CSP) restricts selected resource loads and other browser behaviors. It needs a policy suited to the application's scripts, styles, frames, and integrations. A broad policy can be weak even when the header exists. MDN's CSP guide explains directives and report-only deployment.
Strict-Transport-Security (HSTS) tells a browser to use HTTPS for a host after receiving a valid HTTPS response with the policy. Including subdomains or pursuing preload has wider consequences. Verify HTTPS support and ownership across the intended scope first; see MDN's HSTS reference.
Framing controls such as CSP's frame-ancestors restrict which parents can embed a document. The correct policy depends on whether legitimate embedding is needed. X-Content-Type-Options, Referrer-Policy, and Permissions-Policy address other browser behaviors. The OWASP HTTP Headers Cheat Sheet explains their purposes and implementation considerations.
Do not paste a universal policy into production
A copied policy can break a payment widget, a map, an embedded form, or the application's own scripts. Choose a representative route set and test the functions those routes need.
Prepare this rollout note with the developer responsible for the site:
Policy and specific risk addressed:
Routes and subdomains affected:
Required third-party integrations:
Proposed value and rationale:
Staging checks and expected behavior:
Release and rollback method:
Post-release evidence:
The right owner may be the application developer, hosting provider, or CDN administrator. Confirm which layer actually sets the response so competing configurations do not silently override each other.
Verify policy and behavior together
Inspect the returned header after the change. Then test the relevant user journeys in a browser. A header checker may see the new value while a required embedded service fails for visitors.
If using CSP reports, plan their destination and handling deliberately. Reports can contain URLs and other operational detail; review what you collect before sending it to a service.
Keep the result narrow
A verification note should name the policy, tested routes, and observed behavior. It should not say the site is “fully secure.” Headers do not establish that authentication, authorization, dependencies, or backups are sound.
Check an authorized public page, then use the security repair sequence to turn the finding into a tested change. For the wider operating controls, read the small-business security checklist.