HTTP Security Header Hardening

The response headers that tell a browser how to treat your site — HSTS, Content-Security-Policy, frame and referrer policy, permissions policy — set for one site and checked against an external header scanner. Most of them are absent by default, and their absence is the first thing anyone reviewing you from outside will notice. It is a cheap, visible gap to close.

What you get

• HSTS, Content-Security-Policy, frame, referrer and permissions policy configured for one site
• The content policy run in report-only mode first, so a rule that would break your own scripts is caught before it breaks them
• A before-and-after reading from an external header scanner
• The configuration handed over where your stack actually reads it from — server config, edge rules or framework middleware — so it survives your next deploy

What this does not cover

• Any flaw in the application itself — headers tell a browser how to behave, they do not correct the code behind the page
• Any search for vulnerabilities: this is a configuration change, not a test, and it will not tell you what else is wrong with the site
• Anything but the one site in scope, including its API if that is served from a different hostname
• Keeping the policy current — a content policy goes stale the week somebody embeds a new widget

Who it fits

A site where this has simply never been done and you want the obvious gap closed cheaply. It is not an assessment: if the question is what else is wrong with this host, that is Monthly Vulnerability Scan, and if the question is whether somebody could get in, that is External Penetration Test.