Content-Security-Policy
The one that does the most work: it limits what a page may load and execute, so an injected script has nowhere to run. Also the hardest to add to an existing site.
Two headers that scoring tools still demand do nothing: X-XSS-Protection controls a browser feature that was removed in 2019, and X-Frame-Options is superseded by a CSP directive. A site configured the modern way loses marks for it. So this reports each header with what it prevents, and leaves the arithmetic out.
The one that does the most work: it limits what a page may load and execute, so an injected script has nowhere to run. Also the hardest to add to an existing site.
Tells the browser to use HTTPS next time without asking. Removes the one plain-HTTP request a visitor makes when they type a bare hostname.
The current way to control framing, inside the CSP. It supersedes X-Frame-Options, and browsers prefer it where both are present.
nosniff. One header, no compatibility cost, and it stops a browser guessing that an uploaded file is a script.
If the site has logins or any authenticated action: a Content-Security-Policy, HSTS, and framing control. Those three address real attacks against real users — injected script running with your site's privileges, a plain-HTTP request being intercepted, and a click the visitor believed was theirs landing on your page inside somebody else's frame.
If the site is a brochure with no forms: HSTS and nosniff, and then stop. A CSP on a static marketing site prevents very little, and the effort is better spent elsewhere. Framing an informational page achieves nothing for an attacker.
The CSP rollout is the only hard one. A strict policy breaks inline scripts, and most sites have more of those than anyone expects — analytics snippets, chat widgets, a tracking pixel somebody added for a campaign in 2019. The route that works is Content-Security-Policy-Report-Only with a reporting endpoint: the policy is not enforced, violations are collected, and you find out what would break before anything does. Then enforce the same policy.
One header worth removing rather than adding: a Server or X-Powered-By that includes a version number. It creates no vulnerability by itself, and it does hand a scanner the exact list of exploits worth trying. Suppressing it is a one-line configuration change.
Because a score has to weigh headers against each other, and any weighting is an opinion dressed as a measurement. Worse, the common scoring tools still award points for X-XSS-Protection, which no browser implements, and penalise a site for omitting X-Frame-Options when its CSP already covers framing. A site can improve its grade without improving its security, which is the wrong incentive.
No. It controlled Chrome's XSS Auditor, which was removed in 2019, and Firefox never implemented it. The header is inert in every current browser. It is harmless to leave, and a Content-Security-Policy is what replaced it.
No. frame-ancestors is the current mechanism and browsers prefer it where both are present. Setting X-Frame-Options as well is harmless belt-and-braces for very old browsers, but its absence is not a gap.
Start short — a day or an hour — while you confirm nothing on the domain needs plain HTTP. A long max-age is a commitment: browsers will refuse to reach the site over HTTP for that entire period, including if HTTPS breaks. Once you are confident, a year with includeSubDomains is the usual destination.
A strict one will break anything using inline script or eval, which is a great deal of third-party embed code. That is exactly what report-only mode is for: deploy the policy as Content-Security-Policy-Report-Only, read the violation reports for a couple of weeks, and you will know what breaks before it does.
An expired certificate, a missing header or an exposed port is a finding. Knowing which of them matters on your estate, fixing them without breaking the application, and noticing the next one before a stranger does is the work. That is what we do, continuously rather than as a report.