HTTP security headers
Plan and verify HSTS, Content-Security-Policy, and X-Content-Type-Options without treating header presence as complete browser security.
Reviewed
Check identity
http.security-headers- Finding
- http.security-headers.missing
- Severity
- medium
What the check observes
The scanner requests the HTTPS root within redirect, duration, and response-size limits and records whether three supported header names are present.
The current code-owned set is Strict-Transport-Security, Content-Security-Policy, and X-Content-Type-Options.
Evidence names missing headers only. Raw response headers, bodies, cookies, and scanner output are not retained.
Why the result matters
These browser directives can reduce downgrade, content-injection, and content-type confusion risk when they are configured for the application’s actual behavior.
Presence is a useful baseline signal, but a permissive or incompatible value may provide less protection than its name suggests.
How to investigate
- 1
Confirm which supported headers are absent on the exact HTTPS target and whether an edge or application layer is responsible for response headers.
- 2
Inventory scripts, styles, frames, connections, and legacy browser behavior before designing a Content Security Policy.
- 3
Review subdomain and preload implications before expanding HSTS beyond the tested hostname.
Remediation steps
- 1
Add X-Content-Type-Options with an appropriate `nosniff` directive where compatible.
- 2
Develop a Content Security Policy from observed application dependencies, test it in a controlled environment, and tighten it deliberately rather than copying a generic policy.
- 3
Enable HSTS only after HTTPS is reliable for the intended scope, then choose age and subdomain behavior through the organization’s change process.
Verify the change
Test representative responses in staging and production to confirm the directives are present and the application still works as intended.
Run a new authorized scan to confirm header presence, then use application-specific testing to review directive quality and route coverage.
Limits of this check
- This check verifies presence, not the strength, completeness, or bypass resistance of a header value, and it currently observes the root response rather than every route.
- Passing the check does not prove the application is protected from cross-site scripting, injection, clickjacking, content-type confusion, or transport attacks.