The security headers checklist every website needs
Security basics · 6 min read
Why headers matter
HTTP response headers tell the browser how to treat your site: whether to allow it inside an iframe, which scripts it's allowed to run, whether to ever send a request over plain HTTP. Getting them wrong doesn't break your app, which is exactly why they're so often skipped. There's no visible symptom until someone exploits the gap.
The headers that matter most
Content-Security-Policy (CSP): restricts which scripts, styles, and resources the browser will load and run. The single biggest lever against cross-site scripting (XSS). A CSP with unsafe-inline or unsafe-eval in it defeats most of its own protection; presence alone isn't enough, the directives have to actually be strict.
Strict-Transport-Security (HSTS): tells the browser to never load your site over plain HTTP again, even if a user types http:// or clicks an old link. Without it, an attacker on the same network can downgrade a connection before TLS ever kicks in.
X-Frame-Options / frame-ancestors: prevents your site from being loaded inside an iframe on someone else's page, which is what clickjacking attacks rely on.
X-Content-Type-Options: nosniff: stops the browser from guessing a file's type based on content, which closes off a class of attacks where a malicious file disguised as an image gets executed as a script instead.
Referrer-Policy: controls how much of your URL (including query strings, which sometimes carry tokens) gets leaked to third-party sites when a user clicks an outbound link.
How to check your own site right now
Run curl -sI https://yoursite.com and read the response headers, or open dev tools → Network tab → click the main document request → Headers. Look for each of the five above. Finding the header present isn't the end of the check, though. A CSP that allows * as a source, or an HSTS header with max-age=0, technically exists but protects nothing.
How Auditly checks this
Auditly's headers check looks for all of the headers above, and goes a step further on CSP specifically: it flags unsafe-inline, unsafe-eval, and wildcard source directives as findings in their own right, not just "CSP present, all good." A header that exists but doesn't actually restrict anything gets reported as what it is.