HeaderSec: check the response after the change

A security header only matters once a browser receives it. Between the line you edited and the response a visitor gets sit the application framework, the web server, perhaps a CDN or edge worker, and a redirect or two. Any of those layers can override, duplicate or drop a header. A configuration file that looks right is not the same as a response that is right.

Read what was actually returned

HeaderSec is a scanner for the headers a public site returns. Enter a public HTTP or HTTPS URL and it fetches the response, reports which selected controls are present, missing or weakly configured, and explains what each one asks the browser to do. Its scope is the browser-side defenses: HSTS for keeping requests on HTTPS, Content-Security-Policy for restricting where resources load from, framing and MIME-sniffing protection, and the referrer, permissions, cookie and cross-origin policies that limit what a page discloses or allows.

It reads and grades. It does not modify the target or try to exploit it, and it refuses private, loopback and internal addresses. HeaderSec is owned by VMCSoft Digital and published and operated by ViWeb Technology.

Scan at the moment a header can quietly disappear

The useful habit is to scan after every change that could touch the response, not once a year. An illustrative case: a team moves a site behind a new CDN. The origin still sends HSTS and a framing policy, but the edge layer now adds its own header set, and the two disagree. Nothing visibly breaks. A scan of the public URL shows the headers a browser now receives, so the disagreement becomes something you can see and fix. The same applies after a framework upgrade, a hosting move or a new redirect chain.

HeaderSec’s security headers guide covers the other half of the check. A header being present is not the finish line. After deploying, exercise sign-in, checkout, embeds and third-party widgets, and watch the browser console for blocked resources. A Content-Security-Policy copied from another site can be syntactically perfect and still break a legitimate flow, which is why the guide suggests a report-only policy first and tightening from what you observe.

What a good score does not mean

A strong result is evidence of browser hardening, not a security certification. The scan does not examine application code, authorization, third-party dependencies or the infrastructure underneath, and no header scan covers every class of vulnerability. Treat it as one input to a broader review. Remediation is also site-specific: the guide’s configuration snippets show syntax, and the right values depend on what your application genuinely needs.

Teams that want a record can use the API to run the same scan from a script or CI job and keep history in the dashboard. For everyone else the next step is simpler. The next time a deployment, CDN rule or hosting move touches your site, scan the public URL afterwards and read what came back.