HTTP Security Headers Explained: CSP, HSTS, and More
Your application code can be perfect and still be vulnerable if HTTP response headers are misconfigured. Headers tell the browser what it is allowed to do with your page — which scripts to run, whether to upgrade to HTTPS, and if your site can be embedded in an iframe.
Content-Security-Policy (CSP)
CSP is the most powerful header for preventing cross-site scripting (XSS). It defines which sources are trusted for scripts, styles, images, fonts, and connections. A weak CSP with 'unsafe-inline' or wildcards provides little protection.
- Start with default-src 'self' and add directives only as needed.
- Use nonces or hashes for inline scripts instead of 'unsafe-inline'.
- Set object-src 'none' and base-uri 'self' to block common injection vectors.
- Roll out with Content-Security-Policy-Report-Only before enforcing.
Strict-Transport-Security (HSTS)
HSTS tells browsers to always use HTTPS for your domain, even if a user types http:// or clicks an insecure link. Set max-age to at least one year (31536000) and include includeSubDomains for full coverage.
X-Frame-Options and frame-ancestors
Clickjacking attacks embed your site in a transparent iframe to trick users into clicking hidden buttons. X-Frame-Options: DENY or SAMEORIGIN prevents this. CSP frame-ancestors is the modern replacement and supports finer control.
Other headers worth setting
- X-Content-Type-Options: nosniff — stops MIME-type sniffing attacks.
- Referrer-Policy: strict-origin-when-cross-origin — limits referrer leakage.
- Permissions-Policy — disables camera, microphone, geolocation unless needed.
How LoopNode grades your CSP
LoopNode fetches live response headers on every security audit, parses your CSP directives, assigns a letter grade (A–F), and surfaces specific weaknesses like unsafe-inline or missing object-src. You also get tiered recommendations — from quick wins to advanced hardening — so you can improve policy incrementally without breaking production.