Security Headers Checklist for Websites

What security headers are, and are not

A response to a browser request carries headers, small name and value pairs. Some control caching or content type; others tell the browser to behave more defensively. They are cheap, they act on the visitor's side, and they limit the damage of particular classes of problem such as downgrade to HTTP, injected scripts, content-type confusion and unwanted framing.

They are not a substitute for secure code, patching or access control, and a collection of headers is not a security score. A site can send every header in this list and still be vulnerable, and a careful site with fewer headers can be sound. Use the checklist to remove avoidable weaknesses, not to chase a grade. The DNS Tools Security Headers Checker reports each header with a verdict and deliberately offers no overall number.

The checklist

Roughly ordered from lowest to highest risk of breaking something.

• X-Content-Type-Options: nosniff: stops browsers guessing file types. Low risk, provided scripts and styles are served with correct Content-Type values.
• Referrer-Policy: controls how much of a page's URL is shared with other sites. strict-origin-when-cross-origin is a balanced choice; no-referrer suits sensitive applications.
• Framing protection: Content-Security-Policy frame-ancestors, with X-Frame-Options as the older equivalent. Prevents other sites embedding your pages for clickjacking. Check legitimate embedders first.
• Strict-Transport-Security (HSTS): tells browsers to use only HTTPS for your host. High value, but sticky: roll it out gradually.
• Content-Security-Policy: restricts the sources of scripts, styles and other content. The most powerful and the most likely to break pages; deploy report-only first.
• Permissions-Policy: disables browser features such as camera and geolocation for you and your embeds. Optional hardening.
• Server and X-Powered-By: remove version numbers. Revealing a product name is not a weakness by itself, but exact versions help automated profiling.
• Cross-origin isolation headers (COOP, COEP, CORP): relevant to sites handling sensitive data or needing isolation; optional for most.

HSTS in detail

HSTS tells a browser that has seen the header over HTTPS to refuse plain HTTP for that host for max-age seconds. It protects only the host that sends it, plus subdomains if includeSubDomains is present. The header is ignored when received over HTTP. Because browsers store the policy, a certificate fault later becomes a hard failure with no click-through, so be sure certificate renewal is reliable first.

includeSubDomains forces HTTPS on every subdomain, including forgotten internal or legacy hosts that only speak HTTP; audit them before adding it. Preload goes further by shipping the policy inside browsers. It requires a max-age of at least a year, includeSubDomains, the preload token and an HTTP to HTTPS redirect, and it is hard to undo, because removal depends on list updates and browser releases. Treat preload as a long-term commitment, not a quick win. The HSTS Checker shows eligibility reasoning without claiming list membership.

CSP in detail

A Content-Security-Policy is enforced when sent as Content-Security-Policy, and observational when sent as Content-Security-Policy-Report-Only. Violations under report-only are reported but not blocked, which is how you discover what your pages load before you restrict it. A weak point to avoid is allowing 'unsafe-inline' for scripts without a nonce, hash or 'strict-dynamic', because injected inline script then runs. Wildcards and any-https sources are broad, and object-src and base-uri are worth setting explicitly. Start from a restrictive base and add only needed sources. The CSP Checker separates enforced from report-only and lists risky sources.

Rolling out safely

Prerequisites: know where headers are configured (web server, framework, CDN), who owns each layer, and how to roll back. The most common failure is two layers each adding a header, which produces duplicates or conflicting values; set each header in exactly one place.

1. Inventory current headers on the landing page and on a few representative paths, including static files and error pages.
2. Add nosniff and a referrer policy. Test pages and downloads.
3. Add framing protection after identifying legitimate embedders.
4. Start HSTS with a short max-age and no includeSubDomains. Increase in stages once the certificate process is proven.
5. Introduce CSP in report-only mode, review reports, tighten, then enforce. Keep a copy of the next stricter policy in report-only.
6. Re-check after every deployment that touches the proxy, CDN or web server configuration, since changes there often drop headers silently.

What a header checker cannot see

A checker reads one response from one location. It does not see headers on other paths, on static assets served by another host, or on authenticated pages. Sites using bot protection may answer an automated client with a challenge, so the real headers are never observed. Policies delivered through HTML meta tags are not read. And some checks are structural: a CSP that looks strict may still break your application or leave a gap in a place the tool cannot judge. Verify in real browsers with the developer console open, and treat the checker as a first pass.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09