The cheapest control you're probably missing

Most hardening costs money or engineering time. HTTP security headers cost neither — they're a few lines in your web server or framework config that instruct the browser to refuse whole categories of attack. Yet a scan of almost any small-business site turns up missing or misconfigured headers, because nobody owns them and they're invisible until something goes wrong. They're exactly the kind of low-effort, high-leverage fix that should already be reflected in a security posture score.

A header is a promise the server makes and the browser enforces. Set them right and an attacker who finds an XSS bug or a downgrade opportunity gets a browser that simply won't cooperate.

Start with the three that pay for themselves

You don't need all of them on day one. Rank by risk reduced per minute of effort:

  1. Strict-Transport-Security (HSTS). Forces every future request over HTTPS, defeating SSL-stripping and protocol-downgrade attacks. Start with max-age=31536000; includeSubDomains and only add preload once you're certain every subdomain is HTTPS-only — preload is hard to undo.
  2. Content-Security-Policy (CSP). The single strongest defense against cross-site scripting. It tells the browser exactly which sources of scripts, styles, and images are allowed, so an injected <script> from an attacker's domain never executes.
  3. X-Content-Type-Options: nosniff. One value, no downside. Stops the browser from second-guessing your declared content types — the trick behind several "upload an image that's secretly JavaScript" attacks.

CSP is the hard one — roll it out in report-only mode

CSP breaks things if you ship it blind, because real sites pull scripts and styles from more places than anyone remembers. The safe path:

  1. Deploy Content-Security-Policy-Report-Only first. It enforces nothing but reports every violation to an endpoint you specify.
  2. Watch the reports for a week. Each violation is either a legitimate source to allow or an injection you just caught.
  3. Tighten until the report stream is quiet, then flip the header from report-only to enforcing.

Avoid unsafe-inline and unsafe-eval — they reopen the hole CSP exists to close. Use nonces or hashes for the inline scripts you genuinely need.

The rest, briefly

  • X-Frame-Options: DENY (or CSP's frame-ancestors) blocks clickjacking by refusing to render your page inside someone else's iframe.
  • Referrer-Policy: strict-origin-when-cross-origin stops full URLs (with their query strings) from leaking to third parties.
  • Permissions-Policy disables browser features you don't use — camera, microphone, geolocation — shrinking the attack surface.

Verify, then keep verifying

Setting a header once isn't the job; keeping it set is. A framework upgrade, a new CDN, or a reverse-proxy change can silently strip a header you configured a year ago. This is configuration drift, the same failure mode that continuous compliance monitoring is built to catch — and a header that quietly disappeared should resurface as a finding, not a surprise in your next pen test. Check headers on every deploy, not once.

Security headers are the rare control with no licensing cost, no performance hit, and no excuse for skipping. Turn them on, watch the reports, and verify they stay on.