Security headers
HTTP response headers such as Strict-Transport-Security or X-Content-Type-Options that instruct browsers to enforce additional protections on top of whatever the server itself does.
Why browsers, not the server, enforce these
Security headers work by instructing the visitor's browser to apply extra protections, such as refusing to load the page over plain HTTP or blocking certain types of embedded content, rather than doing anything on the server side beyond sending the instruction.
The most commonly missing ones
Strict-Transport-Security, which forces HTTPS on future visits, and X-Content-Type-Options, which stops browsers from guessing file types in a way that can be abused, are frequently absent even on otherwise well-configured servers.
Frequently asked questions
Do security headers replace the need for TLS?
No. Several security headers, like Strict-Transport-Security, specifically depend on TLS already being in place; they reinforce it rather than substitute for it.
How do I check which security headers a site is currently sending?
Browser developer tools show response headers directly, and several free online header-scanning tools summarize what is present and what is commonly recommended but missing.
Can adding security headers break an existing site?
Occasionally, if a header like Content-Security-Policy is too restrictive for how the site actually loads its own resources; headers should be tested rather than copied blindly from a generic template.
Want to see where your own server stands?
Run the free, read-only server check, or open the Security Lab and watch the detect, contain, recover, verify loop in action.
Get your free server checkOpen the Security Lab