Guides · AuditLume

Web security headers: what they indicate and what they do not

Interpret HSTS, CSP and protective response headers as observable layers rather than proof that a site is secure.

What the scanner observes

AuditLume reads headers from the final public response. On HTTPS it checks HSTS and also looks for Content-Security-Policy, X-Content-Type-Options and Referrer-Policy. Their presence can reduce particular browser risks; their absence does not prove exploitation, and their presence does not rule out vulnerabilities.

The response checks cover HSTS on HTTPS, Content-Security-Policy, X-Content-Type-Options set to nosniff and Referrer-Policy. Presence is not a vulnerability assessment.

AuditLume reads the final public response and initial HTML only; the finding remains a prompt for verification rather than a conclusion about the whole organisation.

A responsible manual review

Automated output is an invitation to investigate, not a verdict. Check representative pages, complete the real user task and include people with different devices or needs. Treat unusual results as context to understand rather than a score to optimise blindly.

How to prioritise

Review the evidence on the exact public page, record the current state, make one controlled change and check again. Keep screenshots or response details when they help colleagues understand the decision.

  1. Inventory headers on representative responses, not only the home page.
  2. Introduce policies in a controlled environment and monitor breakage.
  3. Use a restrictive CSP that reflects the resources the site needs.
  4. Combine header work with updates, access control and professional testing.

Limits to remember

A positive signal does not certify accessibility, privacy, security, legal compliance or search performance. A missing signal does not by itself prove harm. AuditLume reads public responses and initial HTML; specialist, legal and manual reviews remain separate activities.