HTTP Security Headers Checklist: Configure CSP, HSTS, and Browser Protections Safely

Overview

HTTP security headers are response headers that tell a browser how to handle content loaded from your application. They do not replace authentication, authorization, input validation, dependency updates, or secure application design. They add browser-enforced guardrails around common risks such as cross-site scripting, clickjacking, MIME confusion, unwanted referrer disclosure, and accidental permission use.

A useful security-header plan starts with the resources your application actually serves. A static documentation site may need a relatively small policy. A server-rendered application may load scripts, fonts, images, frames, and API requests from several origins. An API may need fewer browser-facing headers but still benefits from transport and content-type protections. Do not copy a policy from one project into another without reviewing its dependencies.

For background on testing the surrounding application, pair this checklist with a web app deployment checklist and an API debugging workflow. Headers are most effective when verified as part of the same release process as routes, assets, and infrastructure.

Checklist by scenario

Baseline for a static site

• Serve every page and asset over HTTPS.
• Add X-Content-Type-Options: nosniff and ensure CSS, JavaScript, fonts, images, and downloads have correct media types.
• Set a deliberate Referrer-Policy, rather than leaving referrer behavior to an unreviewed default.
• Use a restrictive CSP that names the actual script, style, image, font, and connection sources. Avoid broad source expressions unless you have documented a reason.
• Set frame-ancestors 'none' when the site must never be embedded. If it is embedded by a known origin, list that origin explicitly.
• Review whether browser capabilities such as camera, microphone, geolocation, or payment access are needed. Disable unused features with Permissions-Policy.

Baseline for a server-rendered or single-page application

• Inventory inline scripts, inline styles, dynamically generated code, workers, WebSockets, API origins, image CDNs, font providers, analytics, payment services, and embedded content.
• Prefer nonces or hashes for necessary inline code rather than allowing unrestricted inline scripts. Avoid permitting string-to-code execution unless a reviewed dependency requires it.
• Define connect-src for API, WebSocket, and telemetry endpoints. A page that renders correctly can still fail when its browser requests are blocked.
• Define frame-src for content your page embeds, and frame-ancestors separately for sites allowed to embed your page.
• Test login, logout, uploads, downloads, error pages, service workers, and authenticated API calls under the final policy.

Baseline for an API

• Use HTTPS and confirm that credentials, tokens, and sensitive responses are not exposed through avoidable redirects or overly broad cross-origin behavior.
• Return accurate content types and add X-Content-Type-Options: nosniff.
• Set a suitable Referrer-Policy on browser-facing endpoints, while remembering that CORS, authentication, and authorization must be configured independently.
• Do not assume that adding security headers makes an API safe for every origin. Review allowed origins, methods, headers, credentials, and preflight responses as one policy.
• Use an API client or browser network panel to check successful responses, errors, redirects, and preflight requests. The JWT debugging guide can help inspect token-related failures, but never paste production secrets into an online utility.

Roll out CSP with report-only mode

Start by recording the resources each page needs. Add a Content-Security-Policy-Report-Only response header with a conservative draft policy and collect violations in a controlled reporting destination. Treat reports as evidence, not automatic permission: a violation may identify a required integration, an obsolete asset, a typo, or an injection attempt.

Group reports by directive and URL, remove unused dependencies, and document every required exception with an owner. Test representative routes in a staging environment, then deploy an enforcing CSP to a small production slice or low-risk route where your release process allows it. Keep report-only monitoring alongside enforcement so future integrations are visible before they fail.

What to double-check

1. Header scope: Confirm whether the policy is applied at the CDN, reverse proxy, web server, framework middleware, or route level. Multiple layers can overwrite or combine headers in surprising ways.
2. HSTS readiness: Before enabling Strict-Transport-Security, verify that HTTP redirects to HTTPS, certificates renew correctly, and required subdomains support HTTPS. Treat long durations and subdomain coverage as deliberate operational decisions, not defaults to paste blindly.
3. Redirects and errors: Inspect 3xx, 4xx, 5xx, login, and asset responses. A secure header missing from an error route can create inconsistent browser behavior.
4. Third-party changes: Recheck analytics, payment, identity, maps, video, and support integrations after vendor or configuration changes. Add only the exact origins and directives required.
5. Browser behavior: Test with the browsers and devices your users rely on, including authenticated flows and embedded contexts. Use the browser compatibility testing matrix to record results rather than relying on one local browser.
6. Policy exceptions: Maintain a worksheet containing the route, header, exception, business reason, source origin, owner, test evidence, and removal or review date.

Common mistakes

Copying a “perfect” CSP: A policy that works for one site may block another site’s bundles, workers, fonts, or API calls. Generate yours from an inventory and test it.

Using CSP as a substitute for fixing injection: CSP is a browser control, not permission to leave unsafe output handling, template escaping, or dependency risks unresolved.

Allowing broad wildcards for convenience: Wildcards can hide ownership and expand the number of places content may come from. Prefer specific origins and remove temporary allowances.

Confusing embedding directives: frame-src governs what your page may load in a frame; frame-ancestors governs who may frame your page. They solve different problems.

Enabling HSTS before the migration is complete: A host or subdomain that still depends on HTTP can become inaccessible to browsers that honor the policy. Roll out transport changes in stages.

Testing only the homepage: Security headers affect routes and resources differently. Include dashboards, forms, file responses, API calls, redirects, error pages, and embedded flows.

When to revisit

Make this checklist part of your release and infrastructure review rather than a one-time hardening task. Revisit headers before a domain migration, HTTPS change, major frontend or Node.js upgrade, new CDN configuration, identity-provider change, or third-party integration. The Node.js version upgrade checklist is useful when server middleware or response handling changes.

At least during planned seasonal or recurring security reviews, confirm that every header is still present, every CSP exception has an owner, and report-only findings are understood. Also review when browser capabilities, framework defaults, deployment tools, or security guidance change. Keep a dated test record, compare production responses with the intended configuration, and remove exceptions that no longer have a business purpose.

Practical next step: capture response headers from a representative public page, authenticated page, API response, redirect, and error response. Record gaps in the worksheet, deploy CSP in report-only mode, test the critical user journeys, then promote only the policies your team can explain and maintain.