HTTP security headers explained
Security headers let a website tell the browser which protections and restrictions should apply to a response. They are useful defence-in-depth controls, but simply having a header is not the same as having a good policy.
Strict-Transport-Security (HSTS)
HSTS tells supporting browsers to use HTTPS for the site for a period of time. Once a browser has received a valid HSTS policy over HTTPS, it can upgrade future HTTP attempts automatically.
HSTS should be introduced carefully after HTTPS is reliably configured. Long durations and subdomain coverage can make mistakes painful to unwind, and preload submission is a separate deliberate step.
Content-Security-Policy (CSP)
CSP can restrict where scripts, styles, frames, images and other resources are allowed to come from. A strong policy can reduce the impact of content injection, but a badly designed policy can also break legitimate functionality.
It is often sensible to observe or report violations while building a policy rather than immediately enforcing a restrictive configuration you have not tested.
Other useful browser controls
X-Content-Type-Options: nosniff tells browsers not to reinterpret certain resource MIME types. Referrer-Policy controls how much referrer information is sent to other sites. Permissions-Policy can limit browser features such as camera, microphone or geolocation.
For framing, modern CSP uses the frame-ancestors directive. X-Frame-Options remains common as an older control for clickjacking protection.
Inspect a site's response headers
IPGetter checks the final HTTP response for common security headers and shows the values the browser is actually being sent.
Missing does not always mean vulnerable
A header checker can tell you what is present, missing or configured in an obviously unusual way. It cannot determine the complete security posture of an application.
For example, CSP can provide valuable protection, but the right directives depend heavily on how a specific application loads scripts and other resources. Treat header results as configuration evidence, not as an automatic security grade.
A practical review order
- Make HTTPS reliable first. HSTS should not be used to hide a broken TLS deployment.
- Inspect the live response. Reverse proxies and CDNs can change headers after the application generates them.
- Test policies in the real app. Especially CSP and Permissions-Policy.
- Retest after deployment changes. Security headers are easy to lose when moving between servers or proxy layers.
Prefer the command line?
Check the live HTTP response and redirect chain from the Terminal.
> status https://example.com
Run in Terminal ->