Website security headers: a pre-launch checklist

Website security headers tell a browser how to handle transport, scripts, content types, referrer data, and device features. Check them on the deployed URL before launch because a proxy, CDN, or hosting rule can change the response after your application code runs.

This pre-launch checklist covers five headers that give developers useful browser controls: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Treat the example values as a starting point. Your routes, third-party services, and subdomains determine the policy you can enforce.

Inspect website security headers on the final response

Start with the public HTTPS URL that users will open. Follow redirects, then inspect the final response headers:

curl -sSIL https://example.com/

The output may include one header block for an HTTP redirect and another for the final HTTPS document. Review the last response. A header attached only to the redirect does not prove that the HTML response sends the same policy.

Use browser developer tools for a second check. Open the Network panel, reload the page, select the document request, and inspect Response Headers. Repeat the test on a route with different hosting or application middleware, such as /docs, /app, or a server-rendered product page.

Add the result to your website launch checklist. Keep the URL, response status, redirect count, and observed header values together so another developer can reproduce the check.

1. Set Strict-Transport-Security after HTTPS works

Strict-Transport-Security, often called HSTS, tells a browser to use HTTPS for future requests to the host. Browsers ignore HSTS when a site sends it over HTTP, so place the header on the final HTTPS response. MDN's Strict-Transport-Security reference explains the host, expiration, subdomain, and preload behavior.

Strict-Transport-Security: max-age=31536000

Test every active subdomain before you add includeSubDomains. That directive extends the rule to subdomains, including an old tool or vendor endpoint that may not support HTTPS. Preloading has a wider and harder-to-reverse effect, so review the preload requirements and recovery plan before you request it.

Confirm these points:

• HTTP redirects once to the intended HTTPS URL.
• The final HTTPS response sends HSTS.
• The certificate is valid for each host covered by the policy.
• The team has reviewed includeSubDomains and preload separately.

Follow the HSTS header setup and testing guide for staged lifetimes, host coverage, exact-response checks, and rollback limits.

2. Build a Content Security Policy from real dependencies

A Content Security Policy, or CSP, limits the sources a page can use for scripts, styles, images, frames, and other resources. It can reduce the impact of injected content, but a copied policy can also block login widgets, analytics, fonts, images, or application code.

List the resources the production page loads before you write the policy. Start with restrictive fallback directives, then allow each required origin under the narrowest relevant directive:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' https: data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

This sample suits a page whose scripts and styles come from its own origin. It will break sites that need inline code or third-party resources. MDN's Content-Security-Policy reference documents the available directives and source expressions.

Roll out a complex policy with Content-Security-Policy-Report-Only first. Review violation reports and browser console messages, fix the source list, then send the enforcing Content-Security-Policy header. Keep the report-only policy during tuning, but do not confuse it with enforcement.

Follow the CSP testing guide to inspect combined policies, collect violation evidence, and test browser tasks before enforcement.

Avoid adding broad sources to silence errors. Trace each blocked request to a product requirement, remove unused dependencies, and prefer nonces or hashes when the application needs inline code.

3. Stop MIME type guessing

Send the right Content-Type for each response and add this header:

X-Content-Type-Options: nosniff

nosniff tells browsers to respect declared MIME types in relevant script and style requests instead of guessing. The MDN X-Content-Type-Options reference describes how browsers apply it.

Check an HTML route, a JavaScript asset, and a stylesheet. A nosniff header cannot repair a server that labels JavaScript as text/plain or returns an HTML error page at a script URL. Fix the response status and Content-Type as well.

4. Choose a Referrer-Policy

Browsers may send the current page URL in the Referer request header when a visitor follows a link or loads a cross-origin resource. A referrer policy controls how much of that URL leaves the page.

Referrer-Policy: strict-origin-when-cross-origin

That value sends the full referrer for same-origin requests, sends only the origin to a secure cross-origin destination, and omits the referrer on a downgrade from HTTPS to HTTP. Review MDN's Referrer-Policy directive table before choosing a stricter value such as no-referrer.

Do not place secrets, reset tokens, or personal data in URLs. Referrer policy reduces exposure; it does not make sensitive query strings safe.

5. Restrict browser features with Permissions-Policy

Permissions-Policy lets a site allow or deny browser features such as camera, microphone, and geolocation for the top-level page and embedded frames. Disable features the page does not use, then grant required features to named origins.

Permissions-Policy: camera=(), microphone=(), geolocation=()

Test any payment, identity, video, map, or embedded support flow after changing the policy. An iframe may need a compatible response policy and an allow attribute. The MDN Permissions-Policy reference covers policy syntax and inheritance.

Add HTTP security headers in one response layer

Choose one owned layer for the final policy: application middleware, the web server, or the edge platform. Scattered rules make overrides and route gaps hard to review. This generic response block shows the five headers together:

Strict-Transport-Security: max-age=31536000
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

OWASP's HTTP Security Response Headers Cheat Sheet provides broader guidance for choosing and reviewing security-related headers. Compare that guidance with your browser support, application threats, and deployment architecture.

Check more than the homepage. Test representative HTML routes, redirects, error pages, and authenticated responses. A static hosting rule may cover assets but miss server-rendered routes, while application middleware may skip errors produced by a proxy.

Put the security headers checklist in CI

Once the team approves the values, assert stable parts of the contract after deployment. A small shell check can fail when a required header disappears:

headers="$(curl -fsSIL https://example.com/)"
printf '%s' "$headers" | grep -qi '^strict-transport-security:'
printf '%s' "$headers" | grep -qi '^content-security-policy:'
printf '%s' "$headers" | grep -qi '^x-content-type-options: nosniff'
printf '%s' "$headers" | grep -qi '^referrer-policy:'
printf '%s' "$headers" | grep -qi '^permissions-policy:'

Presence checks catch deletion, not weak values or application vulnerabilities. Keep a reviewed expected-value test for policies your team owns, exercise important routes in a browser, and schedule a public-URL check after deployment. The website regression testing guide shows how to store a baseline and separate a confirmed change from missing evidence.

Run a public website security headers check

Run a Slop Audit against the public URL after you deploy the headers. The report records evidence for HTTPS, HSTS, CSP, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy on the observed response. Review the finding evidence, fix the response layer, and rescan the same route.

Slop Audit checks whether these headers are present and whether X-Content-Type-Options uses nosniff; it does not prove that a CSP is safe, certify the website, or replace a security review. Use the website audit report example to turn an observed header gap into an owned release task.

Your sign-off should contain the final URL, the exact header values, routes tested, browser-flow results, and the reviewer who accepted the policy. That record gives CI and later audits a concrete baseline.