Web Security

HTTP Security Headers Checklist: CSP, HSTS, and More

A practical checklist for reviewing Content-Security-Policy, HSTS, framing controls, content types, referrer policy, permissions policy, and cookie security.

September 5, 2026 at 11:31 AM · Duck Cloud Editorial

Table of contents

HTTP Security Headers Checklist: CSP, HSTS, and More

HTTP response headers are a compact security control surface. They can reduce cross-site scripting impact, prevent clickjacking, limit sensitive referrer data, enforce HTTPS, and disable browser capabilities an application does not need.

Use this checklist during deployment reviews and after CDN, proxy, or framework changes.

Inspect the final public response

Check the response a real visitor receives, not only the origin server. Reverse proxies, CDNs, hosting platforms, and middleware can add, remove, or duplicate headers. Duck Cloud's [HTTP Header Checker](/tools/http-header-checker) helps inspect the final response and redirect chain.

Test the canonical HTTPS URL, important application routes, error pages, static assets, and redirects. Security headers can vary between them.

Content-Security-Policy

A Content Security Policy controls where scripts, styles, images, frames, fonts, and connections may load from. Start in report-only mode for an existing application, review violations, then enforce a policy that matches actual dependencies.

A strong baseline commonly includes:

  • default-src 'self' as a restrictive fallback;
  • explicit script-src, style-src, img-src, and connect-src directives;
  • object-src 'none' unless legacy plugins are required;
  • base-uri 'self' to restrict base URL changes;
  • frame-ancestors 'none' or an exact allowlist;
  • nonces or hashes instead of unsafe-inline for scripts.

Do not paste a generic policy into production without testing. A policy that breaks authentication, analytics, payments, or application bundles will quickly be disabled.

Strict-Transport-Security

HSTS tells browsers to use HTTPS for future requests. A common production value is Strict-Transport-Security: max-age=31536000; includeSubDomains.

Add preload only after confirming every subdomain supports HTTPS and understanding browser preload removal procedures. A long max-age can outlive a mistaken configuration.

Framing, content type, and referrers

Use CSP's frame-ancestors directive to control which sites may embed your pages. X-Frame-Options: DENY or SAMEORIGIN remains useful for older clients.

Set X-Content-Type-Options: nosniff and return accurate content types. Choose an explicit Referrer-Policy; strict-origin-when-cross-origin is a practical default for many sites.

Permissions Policy

A Permissions Policy disables browser features the site does not use. Consider restricting camera, microphone, geolocation, payment, USB, and other sensitive capabilities. Test embedded documents separately because inheritance rules matter.

Authentication cookies should generally use:

  • Secure so they travel only over HTTPS;
  • HttpOnly to block direct JavaScript access;
  • an appropriate SameSite value;
  • the narrowest practical Domain and Path;
  • a deliberate expiration or session lifetime.

Use cookie prefixes such as __Host- when their restrictions fit the application.

Review checklist

  • Inspect the final HTTPS response and redirects.
  • Enforce a tested Content Security Policy.
  • Add HSTS after every relevant hostname is HTTPS-ready.
  • Restrict framing with frame-ancestors.
  • Set X-Content-Type-Options: nosniff.
  • Choose an explicit Referrer Policy.
  • Disable unnecessary browser capabilities.
  • Review authentication cookie attributes.
  • Remove obsolete or conflicting duplicate headers.
  • Recheck after CDN, proxy, framework, or authentication changes.

Security headers work best as tested application configuration, not a score-chasing exercise. Start with the threats and browser features your site actually uses, then make each restriction measurable and maintainable.

Advertisement