A missing header is not a breach
Most security-header tools are written in the register of an incident report, and it is misleading. None of these headers patches a vulnerability. Each one closes off a specific attack in a specific circumstance — an intercepted first request, an injected script, your page loaded invisibly inside somebody else's. A site without them is not compromised; it is missing defences it would benefit from.
The distinction matters because the wrong reaction is worse than the gap. The most common way a Content-Security-Policy causes harm is somebody copying a strict one from a tool like this into production, watching half their site stop working, and turning the whole thing off. A policy deployed carefully over two weeks beats one deployed confidently in an afternoon.
So the findings here are graded by what they actually cost you. Serving over plain HTTP is critical, because everything else is pointless without it. A missing Permissions-Policy is low, because on most sites it changes nothing at all.
What each header is for, briefly
Strict-Transport-Security tells the browser to remember that your site is HTTPS-only, which closes the window where a visitor's very first request goes out over plain HTTP and can be redirected somewhere else. Content-Security-Policy lists where scripts and styles may come from, so an injected script has no valid origin. X-Content-Type-Options stops browsers second-guessing the content type you declared, which is how an uploaded file gets re-interpreted as script.
X-Frame-Options — or frame-ancestors in a CSP — stops your pages being loaded invisibly inside another site, which is the basis of clickjacking. Referrer-Policy controls how much of your URL is handed to the next site a visitor clicks through to, which matters on any page whose address contains a token or a search term. Permissions-Policy declares which device features your pages and their embedded frames may request.
The cookie attributes are checked too. Secure keeps a session cookie off unencrypted connections, HttpOnly puts it beyond the reach of JavaScript, and SameSite stops it being attached to requests another site started. Those three are what limit the damage when something else goes wrong.
What this cannot tell you
It reads one URL. Headers are frequently configured per location, so a login page can differ from a home page, and checking the home page tells you about the home page.
It does not look at your TLS configuration — cipher suites, protocol versions, certificate chains are a different layer and want a tool built for it. It also cannot tell you whether a Content-Security-Policy that is present is actually correct for your site, because that needs an inventory of everything the site loads. A policy can be there and still permit exactly what it was meant to block.
The report lists these gaps explicitly rather than leaving them out, because a list of findings with nothing said about scope reads as though everything else was checked and passed.