Updated: 22 October 2026.
A website receives a high security-headers score. What can I safely infer from that result?
I can infer that the checker observed certain response headers and evaluated them against its rules. I cannot infer that the website’s access controls, password recovery or business logic are secure.
Headers are worth configuring. Their value becomes clearer when each one is connected to a specific browser behaviour instead of treated as a point on a scoreboard.
Presence does not establish an effective policy
Content Security Policy can restrict which resources a page loads and how some content executes. Its usefulness depends on the directives and exceptions in the actual policy.
A permissive policy may preserve every existing script while offering less protection than its presence suggests. Conversely, a strict policy copied without testing can break a payment flow, embedded application or essential script.
I would distinguish an enforced policy from Content-Security-Policy-Report-Only. Report-only mode is useful for observing violations before enforcement, but it does not block them. A checker should make that distinction visible.
Match the configuration to the site
HSTS tells supporting browsers to use HTTPS for future connections under its rules. I would review the HTTPS readiness of relevant hosts before extending the policy across subdomains or considering preload submission.
Other controls address different risks. For example, content-type handling and framing restrictions serve different purposes from transport security. Their settings should reflect the application’s needs, including any legitimate embedding requirements.
My approach would be to identify the intended protection, inspect the current behaviour, test the change and document any exception. “The scanner asked for this header” is not enough explanation for a production configuration change.
Check more than the homepage
A public checker usually observes a limited set of responses. The login page, an error response, a download and a page reached after authentication may behave differently.
Redirects matter too. I would record the requested URL, the final URL and where a header was observed. A policy on one response does not prove that every other response uses it.
For a checker I was designing, I would want results to show the raw header value, the interpreted effect and the limits of the request. That gives an administrator something they can reproduce and investigate.
A header result feeds into configuration testing and the wider application review; the score alone cannot certify the application.
flowchart TD
A["Observe response headers"] --> B{"Policy matches intended protection?"}
B -->|No| C["Review directives and exceptions"]
C --> D["Test important user journeys"]
B -->|Yes| D
D --> E{"Protection works without breaking the site?"}
E -->|No| C
E -->|Yes| F["Record policy and evidence"]
F --> G["Combine with access and application tests"]
Use the score to start a review
Suppose an illustrative customer portal has an excellent header configuration but lets an ordinary user retrieve another customer’s document. The headers do not correct that authorisation failure.
That is why I would use a header report alongside application testing, dependency maintenance, access reviews and recovery checks. It covers one useful part of the system.
After changing a policy, I would test important user journeys and review violation reports carefully. Those reports can contain URLs and other details, so their collection and retention also need thought.
The result I want is a configuration whose purpose and behaviour the team understands. A grade can help track changes, but the policy, test evidence and exceptions are what another engineer needs to maintain it.