The six security headers your site is judged on

CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. What each one does, what to set it to, and which compliance frameworks check it by name.

Before a security review, before a SOC 2 audit, before a procurement questionnaire — the first thing anyone serious does is run curl -I against your homepage and read your response headers. Six lines of configuration tell a sophisticated reviewer more about your platform's maturity than your marketing site ever will.

HTTP security headers are the cheapest, highest-signal lever in web security: a few lines in your CDN config or middleware buy you measurable protection against XSS, clickjacking, traffic downgrade, and tracker injection. And yet most sites we audit are missing at least three of the six baseline headers. Here is what each one does and what to set it to.

The six headers every site should set

Content-Security-Policy (CSP)

CSP tells the browser which origins are allowed to load scripts, styles, images, fonts, and iframes on your site. A well-tuned CSP eliminates entire classes of cross-site scripting (XSS) — an attacker who manages to inject a script tag finds the browser refuses to execute it because the script source is not on the allowlist.

Start with: default-src 'self'; frame-ancestors 'none'; then watch the browser console for CSP-violation reports as you walk the site, and add legitimate origins one at a time. Use a nonce or hash for inline scripts; 'unsafe-inline' defeats most of CSP's value.

Strict-Transport-Security (HSTS)

HSTS instructs the browser to remember your domain is HTTPS-only and refuse to downgrade to HTTP — even if a user types the URL with no protocol, even if an attacker tries to MITM the first connection. Without HSTS your initial HTTP request is interceptable; the redirect to HTTPS happens only after the browser has already spoken plaintext.

Set: max-age=31536000; includeSubDomains; preload (one year, all subdomains, eligible for browser preload lists). Once you have confirmed every subdomain is HTTPS-only, submit your domain to the HSTS preload list so the protection extends to first-time visitors.

X-Frame-Options (or CSP frame-ancestors)

Prevents your site from being embedded in an iframe on another origin — the prerequisite for clickjacking attacks. Modern advice is to use frame-ancestors 'none' in your CSP, which supersedes X-Frame-Options. Keep X-Frame-Options around for older browsers, set to DENY or SAMEORIGIN.

X-Content-Type-Options: nosniff

Tells the browser not to guess content types — so an attacker who can upload a file ending in .txt cannot trick the browser into executing it as JavaScript. Two words of configuration that close an entire category of MIME-confusion attacks.

Referrer-Policy

Controls how much of the referring URL gets sent when a user clicks a link out of your site. strict-origin-when-cross-origin is the widely-accepted default — your origin is leaked, the full path is not. Critical for HIPAA-handling and high-trust sites because path-component leakage to third parties has been the root cause of multiple PHI-disclosure incidents.

Permissions-Policy (formerly Feature-Policy)

Selectively disables browser features your site does not use: camera, microphone, geolocation, USB, payment, etc. Reduces the attack surface of any cross-origin iframe you embed and signals deliberate platform hygiene to reviewers.

Why headers move the needle in audits

Security headers map directly to several compliance frameworks:

• SOC 2 Trust Service Criterion CC6.7 (restricted transmission of data) — HSTS is the headline evidence.
• HIPAA Security Rule § 164.312 (technical safeguards) — HSTS, CSP, and Referrer-Policy all show up in the technical safeguards control matrix.
• PCI-DSS Requirement 4 (encrypt transmission of cardholder data) — HSTS is part of how you prove you are encrypting consistently, not just on the checkout page.
• Enterprise vendor security questionnaires (SIG, CAIQ, custom) — they all ask about HSTS and CSP by name.

The procurement reality: if you fail a vendor security review on headers, the conversation often ends before it starts. Reviewers see no-headers as a proxy for “this team hasn't done the basics” — fairly or not.

How to ship the fix in an afternoon

1. Audit current state — run a Plumb scan against your production domain. The Security section of the report lists exactly which headers are missing or weak. curl -I https://your-domain.com is a sanity check.
2. Set the easy four first — HSTS, X-Frame-Options / frame-ancestors, X-Content-Type-Options, Referrer-Policy. These have no side effects on a typical site and can ship in one PR.
3. Roll out CSP in report-only mode first — use Content-Security-Policy-Report-Only for a week, collect violations from real users, refine the policy. Switch to Content-Security-Policy once the report-only mode is quiet.
4. Submit to the HSTS preload list after a month of stable HSTS in production.
5. Re-run the Plumb scan — the Security section of the new report should show every check passed. Save the before/after pair as evidence for your next audit.

What headers don't do

Headers are necessary but not sufficient. They harden the browser boundary; they do not protect against:

• Server-side vulnerabilities (SQL injection, SSRF, deserialization).
• Logic flaws in authorization (IDOR, broken access control).
• Supply-chain attacks (compromised npm packages, malicious dependencies).
• Social engineering of your support team.

Don't treat passing the header checks as “we are secure.” Treat it as “we have done the platform-level hygiene that lets us talk about the harder problems.”