The security-headers checklist changes every three years. Headers that were table stakes in 2018 (X-XSS-Protection) are now considered harmful. Headers that didn't exist in 2018 (Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy) are required for modern isolation. This post walks the current 2026 baseline the Mega Security Analyzer scans for.
The three that actually matter
1. Content-Security-Policy (CSP)
The single most effective defense against stored and reflected XSS. A strict CSP blocks inline scripts and inline event handlers from running even if an attacker injects them into the page.
Minimum baseline that works on most sites:
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self';
Harder but cleaner: use nonces or hashes for inline scripts you genuinely need. Start with Content-Security-Policy-Report-Only so you can see what breaks before you enforce.
The Mega Security Analyzer flags missing CSP as a warning, not a fail, because a misconfigured CSP can break the site. A missing CSP is worse than a lax CSP; a lax CSP is worse than a strict CSP. Work up the ladder.
2. Strict-Transport-Security (HSTS)
Forces browsers to use HTTPS. Without HSTS, a user's first visit to your site is vulnerable to active downgrade attacks (T1557 Adversary-in-the-Middle in the MITRE ATT&CK matrix).
Recommended value:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
The preload directive opts your domain into Chrome's HSTS preload list after you submit at hstspreload.org. Once on the list, the domain is HTTPS-only for every browser that ships the list. Reverse is slow; think carefully before preloading.
3. X-Frame-Options or CSP frame-ancestors
Clickjacking defense. Either header works; modern CSP with frame-ancestors 'self' is preferred because it's more granular and doesn't conflict with CSP's other directives. X-Frame-Options: SAMEORIGIN is the legacy equivalent and is widely still honored.
Send both if you're being careful. Modern browsers respect frame-ancestors over X-Frame-Options when both are present.
The three that are worth shipping but matter less
4. X-Content-Type-Options: nosniff
One-line header that prevents MIME-type-based XSS attacks. Costs nothing, catches a narrow attack class. Always ship it.
X-Content-Type-Options: nosniff
5. Referrer-Policy
Controls how much referrer URL information is sent to other sites. Recommended default:
Referrer-Policy: strict-origin-when-cross-origin
This sends the full URL to same-origin requests (useful for your own analytics), and only the origin (not path + query) to cross-origin requests (privacy-preserving + blocks information-leak attacks).
6. Permissions-Policy
Controls which browser APIs the page can use. Not a security header in the traditional sense; a privacy header. Useful if your site doesn't need camera / microphone / geolocation / payment / USB access and you want to make sure a compromised dependency can't invoke them.
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
The modern isolation pair (COOP + CORP)
Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy are the newer headers most sites don't yet ship. They enable browser process isolation, which defends against Spectre-class side-channel attacks and cross-origin pixel-reading attacks.
Cross-Origin-Opener-Policy (COOP)
Tells the browser: "this document should be isolated from other browsing contexts in a separate process." Recommended value for most sites:
Cross-Origin-Opener-Policy: same-origin
Setting COOP: same-origin is required if you want to use features like SharedArrayBuffer or cross-origin-isolated primitives. Even if you don't use those features, COOP strengthens process isolation as a defense-in-depth.
Cross-Origin-Resource-Policy (CORP)
Tells other sites: "resources from my origin can only be embedded by same-origin documents." Recommended value:
Cross-Origin-Resource-Policy: same-origin
Combined, COOP + CORP make your site eligible for the stronger browser-level isolation mode. The Mega Security Analyzer flags missing COOP and CORP as info, not warnings, because the real-world exposure from not having them is low for most sites. They're nice-to-have.
The header that used to be mandatory and is now actively harmful
X-XSS-Protection
Defense against reflected XSS in the pre-CSP era. Chrome dropped the built-in XSS auditor in 2019. Firefox never implemented it. Edge dropped it in 2020. Safari still respects it but the behavior is unpredictable.
In 2026 the recommendation is either omit the header entirely OR set X-XSS-Protection: 0 (disabled). A buggy legacy XSS auditor can itself be used as an attack primitive.
The server/X-Powered-By header leak
Not a security header; a security anti-pattern. When your server sends Server: Apache/2.4.52 (Ubuntu) or X-Powered-By: PHP/8.1.12 in every response, you're volunteering the exact version an attacker needs to match against a CVE database.
Fix: set both to generic values or remove them entirely.
- nginx:
server_tokens off;+more_clear_headers 'Server' 'X-Powered-By'; - Apache:
ServerTokens Prod+Header unset X-Powered-By - Express:
app.disable('x-powered-by') - Netlify: set
X-Powered-By = ""in_headers
The copy-paste block for Netlify
Drop this in public/_headers for a reasonable 2026 baseline:
/*
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self'; font-src 'self' data:; frame-ancestors 'self'; base-uri 'self'; form-action 'self';
X-Frame-Options: SAMEORIGIN
X-Powered-By:
The CSP here is deliberately loose ('unsafe-inline' for script-src and style-src) because tightening it requires per-site audit. Use this as a starting point and tighten over two to four weeks of Report-Only observation.
Related reading
- Mega Security Analyzer, scans for all six headers plus TLS + DNS
- Security Headers Audit, the headers-only deep audit
- PQC Analyzer, the cryptography layer below the headers
- Server-Side Audit Probes, the backend fortification behind the audit
Fact-check notes and sources
- MDN Web Docs: Content-Security-Policy, Strict-Transport-Security, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy specifications.
- Chrome Blog, 2019, on X-XSS-Protection removal from the XSS auditor.
- OWASP Secure Headers Project, 2026 edition.
- web.dev on COOP + CORP + cross-origin isolation.
- hstspreload.org for the HSTS preload submission process.
This post is informational, not security-consulting or legal advice. Header recommendations vary by site architecture; a CSP that works for a static blog will break a site using third-party analytics and widgets. Always test header changes on staging before production, and keep a rollback plan. Only apply headers to sites you own or have authorization to modify.
