{"id":3361,"date":"2026-06-25T10:15:00","date_gmt":"2026-06-25T10:15:00","guid":{"rendered":"https:\/\/getdarkscout.com\/blog\/?p=3361"},"modified":"2026-06-25T07:10:29","modified_gmt":"2026-06-25T07:10:29","slug":"http-security-headers-checklist","status":"publish","type":"post","link":"https:\/\/getdarkscout.com\/blog\/http-security-headers-checklist\/","title":{"rendered":"HTTP Security Headers Checklist: Every Header You Need in 2026"},"content":{"rendered":"\n

Fewer than 10% of websites have all four critical security headers correctly configured.<\/p>\n\n\n\n

Not missing. Not slightly wrong. Completely absent.<\/p>\n\n\n\n

Security headers are free to implement. They require no code changes to your application logic. They protect against attacks that have been documented for over two decades. And the vast majority of production websites still don’t have them.<\/p>\n\n\n\n

This checklist covers every HTTP security header that matters in 2026: what each one protects against, what the correct configuration looks like, which ones are quick to implement and which require careful tuning, and which deprecated headers you should actively remove because they can make security worse.<\/p>\n\n\n\n

Work through it section by section. By the end of this HTTP Security Headers Checklist, you’ll have a complete picture of your current configuration and exactly what needs to change.<\/p>\n\n\n\n

<\/span>What Are HTTP Security Headers and Why Do They Matter?<\/span><\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

A security header for HTTP is a piece of information that is sent as part of the response headers that your web server sends back with any page you request. It gives an instruction to the browser on how to treat your content.<\/p>\n\n\n\n

Without them, browsers use their most permissive defaults. That means they’ll load scripts from any source, allow your pages to be embedded in iframes on other sites, accept any content type regardless of what you intended to serve, and connect over HTTP even if you’ve configured HTTPS.<\/p>\n\n\n\n

Security headers change those defaults. They tell the browser to only load scripts from sources you’ve explicitly approved, refuse to render your pages inside iframes, enforce HTTPS even if a user types HTTP, and reject content that doesn’t match its declared type.<\/p>\n\n\n\n

The attacks each header prevents aren’t theoretical. Cross-site scripting (XSS)<\/a> remains one of the most common web vulnerabilities. Clickjacking attacks steal credentials through invisible iframe overlays. Protocol downgrade attacks strip HTTPS from connections on shared networks. MIME-sniffing executes uploaded files as scripts. These are documented attack patterns with known defenses, and security headers are those defenses.<\/p>\n\n\n\n

What makes the 95% failure rate remarkable is the cost: implementing these headers requires no changes to your application code. It’s the server configuration. It takes hours for most of them, minutes for several. The protection is immediate. The only explanation for the widespread absence is that developers deprioritize it until an audit or a breach forces attention.<\/p>\n\n\n\n

<\/span>How to Check Your Current Headers<\/span><\/h2>\n\n\n\n

Before working through the checklist, run a baseline audit to see where you currently stand.<\/p>\n\n\n\n

Mozilla Observatory<\/strong> observatory.mozilla.org<\/code> Enter your domain and get a letter grade with specific findings for each header. Grade A or higher is the target. Takes under 30 seconds.<\/p>\n\n\n\n

securityheaders.com<\/strong> securityheaders.com<\/code> Focused specifically on security headers. Shows which are present, which are missing, and flags common misconfiguration issues. Quick and readable output.<\/p>\n\n\n\n

curl from the command line<\/strong><\/p>\n\n\n\n

curl -I https:\/\/yourdomain.com<\/code><\/pre>\n\n\n\n
Returns all response headers directly. Handy to check quickly without the browser or an external tool. Notice the security headers there.<\/p>\n\n\n\n
Open developer tools in the browser (F12) and select Network. Reload the page and then, in a pop-up window, select the first request and then the Headers tab. Response Headers section will show all headers your server sends..<\/p>\n\n\n\n
For a broader website security scan covering headers alongside other vulnerabilities, website scanner<\/a> tools provide a more comprehensive audit in a single pass.<\/p>\n\n\n\n
Run the audit first. Note which headers are missing and which are present but misconfigured. Then work through the priority sections below.<\/p>\n\n\n\n
<\/span>Priority 1: Implement Today (Quick Wins)<\/span><\/h2>\n\n\n\n
These headers are one or two lines of server configuration each. They protect against specific, well-documented attacks and have virtually no risk of breaking your site. Implement all of these before anything else.<\/p>\n\n\n\n
 X-Content-Type-Options<\/h3>\n\n\n\n
What it defends from: MIME-sniffing attacks<\/a>. If you do not set this header, a browser can possibly recognize an uploaded text file as a JavaScript file if the file contents look executable, no matter what the file’s original MIME type was. It is one of the defenses for a specific attack, where an attacker manages to upload a malicious file that later gets executed as a script.<\/p>\n\n\n\n
Correct configuration:<\/strong><\/p>\n\n\n\n
X-Content-Type-Options: nosniff<\/code><\/pre>\n\n\n\n
That’s it. There’s one value, and it’s always nosniff<\/code>. No configuration decisions required. This is a single line that closes an entire category of upload-based attacks. It should be on every website without exception.<\/p>\n\n\n\n
Risk of implementation:<\/strong> Zero. This header tells the browser to respect the MIME type you declare. It doesn’t change behavior for correctly served content.<\/p>\n\n\n\n
X-Frame-Options<\/h3>\n\n\n\n
What it blocks: clickjacking. A hacker makes a malicious page, loads your site into an imperceptible iframe that is layered over the attacker\u2019s page and then tricks visitors into clicking buttons on that page, unknowingly completing actions on your website such as authorizing a payment or setting a new account password.<\/p>\n\n\n\n
Correct configuration:<\/strong><\/p>\n\n\n\n
X-Frame-Options: DENY<\/code><\/pre>\n\n\n\n
Use DENY<\/code> if your site should never be embedded in a frame anywhere. Use SAMEORIGIN<\/code> it if you need your own pages to embed other pages from your own domain.<\/p>\n\n\n\n
Note on CSP frame-ancestors:<\/strong> The Content Security Policy frame-ancestors<\/code> Directive is the modern replacement for X-Frame-Options and takes precedence in browsers that support CSP. However, X-Frame-Options provides backward compatibility for older browsers. Set both.<\/p>\n\n\n\n
Risk of implementation:<\/strong> Low. Only affects whether your pages can be embedded in frames. If you don’t embed your own pages in iframes across different domains, DENY<\/code> is safe.<\/p>\n\n\n\n
Referrer-Policy<\/h3>\n\n\n\n
What it protects against: Leakage of information through the Referer header. If your visitors access your site, then click out to another site, the browser will include the URL they were at before in the Referer header. This can include session ID, userid, search terms, or any number of other things you don’t want spilling over to third parties in the query parameters.<\/p>\n\n\n\n
Correct configuration:<\/strong><\/p>\n\n\n\n
Referrer-Policy: strict-origin-when-cross-origin<\/code><\/pre>\n\n\n\n
Tweets the full URL for same-origin requests (which can be useful for tracking on your own analytics solutions), only the origin (ie. Https:\/\/yoursite.com) for cross-origin (HTTPS) requests and nothing for cross-origin (HTTP).<\/p>\n\n\n\n
Risk of implementation:<\/strong> Low to none for most sites. Your internal analytics still works. External third parties lose the path and query string details they didn’t need anyway.<\/p>\n\n\n\n
X-DNS-Prefetch-Control<\/h3>\n\n\n\n
What it protects against:<\/strong> Unintended DNS lookups. Browsers prefetch DNS for links on a page to speed up future navigation. This can leak browsing behavior information to DNS servers for links your users haven’t actually clicked.<\/p>\n\n\n\n
Correct configuration:<\/strong><\/p>\n\n\n\n
X-DNS-Prefetch-Control: off<\/code><\/pre>\n\n\n\n
In most sites where we are more interested in performance than privacy, one is fine. But if we are serious about user privacy, the browsing behavior should be off.<\/p>\n\n\n\n
<\/span>Priority 2: Implement This Week (Moderate Effort)<\/span><\/h2>\n\n\n\n
These headings will require you to put a little more thought into your exact setup, but they are very simple to get right.<\/p>\n\n\n\n
HTTP Strict Transport Security (HSTS)<\/h3>\n\n\n\n
What it defends you from: protocol downgrade attacks. Without HSTS, someone on a communal network, whether you are using public Wi-Fi, a hotel network, or a coffee shop, can run tools like sslstrip, which will see the very first request in your browser, the request for your domain, and could remove the redirect to a secure https:\/\/ website and deliver the resulting page unencrypted.<\/p>\n\n\n\n
With HSTS, once a browser has seen your HSTS header, it enforces HTTPS internally for the specified duration. The HTTP request never leaves the browser. The window for SSL stripping disappears.<\/p>\n\n\n\n
Correct configuration:<\/strong><\/p>\n\n\n\n
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload<\/code><\/pre>\n\n\n\n