Security Headers — What Your Edge Is and Is Not Sending
This inspects the security-relevant response headers a site returns and grades them: transport security, content policy, framing restrictions, referrer handling and content type enforcement. Each instructs the browser to enforce something on your behalf, and each is absent by default.
Why run it
For an operator the interesting question is not whether the application sets these headers but whether the client receives them. Headers are set and overridden across several layers — framework, web server, reverse proxy, CDN — and a header correctly set by the application can be stripped in front of it. Testing what arrives at the client is the only way to know. Transport security in particular is worth confirming directly, since without it a first visit over plain HTTP is still interceptable regardless of how well the redirect is configured.
Why automate it
Because the loss is silent and the ownership is split. Nothing breaks when a security header disappears — no error, no failed request, no user complaint — so its absence persists until somebody audits. Given that the layers are maintained by different people, a change in any of them can remove a header without the others knowing. Scheduled checking converts a periodic audit into continuous verification, which is appropriate for a control whose failure mode is invisible.
What it gives you
Confirmation that browser-enforced protections are actually reaching browsers, across every layer that can interfere. It closes the gap between configuring a security control and it being in effect.