Englishবাংলা
SubscribeWrite
Latest
Big-O notation explained: time and space complexity for interviewsSoftware testing basics: the test pyramid and what to testClean code and code review habits that make you a better developerREST API design best practices: URLs, status codes and errorsJavaScript and TypeScript roadmap: from first script to full stackPython learning roadmap: from basics to real projectsRead documentation and debug like a developerFrontend developer roadmap: HTML, CSS, JavaScript and beyond

Security headers checklist: HSTS, CSP, frame protection and more

A few response headers close a whole class of attacks. Here is the short list to set, what each does and how to test them.

••2 min read
A checklist of header names

HTTP security headers tell the browser to apply extra protections to your pages. They cost little and block many common attacks. Set them at your web server, CDN or application.

The essential headers

1. Strict-Transport-Security (HSTS). Tells the browser to use HTTPS only for your site for a period.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Start with a short max-age, make sure HTTPS works on all subdomains, then raise it. Add preload only when you are sure, because it is hard to undo.

2. Content-Security-Policy (CSP). Restricts where scripts, styles, images and frames can load from, and can block inline scripts. It is the strongest defence against XSS. Roll it out with Content-Security-Policy-Report-Only first, fix the reports, then enforce. Prefer nonce-based scripts.

3. X-Content-Type-Options: nosniff. Stops the browser from guessing a file's type, which prevents some content-sniffing attacks, especially with uploads.

4. Clickjacking protection: frame-ancestors. Clickjacking hides your page in an invisible frame on another site to trick clicks.

Content-Security-Policy: frame-ancestors 'self'

The older X-Frame-Options: DENY (or SAMEORIGIN) does the same and is still widely used as a fallback.

5. Referrer-Policy. Controls how much of the URL is sent to other sites. A good default: strict-origin-when-cross-origin.

6. Permissions-Policy. Turns off browser features you do not use (camera, microphone, geolocation). For example: camera=(), microphone=(), geolocation=().

7. Cross-origin isolation headers (Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, Cross-Origin-Embedder-Policy). Useful for isolating your pages from other origins; set them if your site does not rely on cross-origin popups or embeds, and test carefully.

Cookies need flags too

  • Secure: send only over HTTPS.
  • HttpOnly: hide from JavaScript.
  • SameSite=Lax (or Strict): limit cross-site sending (helps against CSRF).
  • Consider the __Host- prefix for session cookies.

Headers to remove

Hide detailed server and framework version headers (Server, X-Powered-By). It is not a defence by itself, but it avoids giving away information.

How to test

  • Open the browser developer tools, Network tab, and look at the response headers.
  • Use curl -I https://yoursite.
  • Run an online header scanner such as the Mozilla Observatory or securityheaders.com.
  • Check CSP reports to catch problems after changes.

Where to set them

At the CDN or reverse proxy (Nginx, Cloudflare rules) for all responses, or in the application's middleware. Remember static files and error pages too.

Takeaway: set HSTS, a Content Security Policy, nosniff, frame-ancestors, a Referrer-Policy and secure cookie flags, then test them with a scanner.

Web Security series, Part 2 (more bug classes and hardening): 6 of 6. Previous: XXE: XML external entity attacks and how to disable them.

Keep reading