CentralCSP
Policies

Legacy

Older security headers like X-Frame-Options and Feature-Policy, what replaced them, and whether you still need to send them.

Last update:

Several older security headers have been superseded by newer, reporting-aware policies. This page maps each legacy header to its modern replacement and says whether it is still worth sending, so you can clean up a header set without losing protection.

At a glance

Legacy headerStatusModern replacementReplacement statusStill send it
X-Frame-Options⚠️ DeprecatedCSP frame-ancestors✅ GoodFor old-browser coverage; ALLOW-FROM is obsolete
Feature-Policy⚠️ DeprecatedPermissions-Policy✅ GoodNo
X-XSS-Protection⚠️ DeprecatedCSP (block inline scripts)✅ GoodNo, effectively dead; send 0
report-uri (CSP)⚠️ Deprecatedreport-to + Reporting-Endpoints✅ GoodOnly for old browser versions

X-Frame-Options vs frame-ancestors

X-Frame-Options is legacy

The ALLOW-FROM value is obsolete and modern browsers ignore the whole header when they see it. Use CSP frame-ancestors.

The CSP frame-ancestors directive is the replacement for X-Frame-Options: it takes a full source list, and a supporting browser uses it and ignores the header, so sending both is reasonable defense in depth for old clients. For the value-by-value mapping and which to send, see X-Frame-Options vs frame-ancestors.

Feature-Policy vs Permissions-Policy

Feature-Policy is deprecated

Feature-Policy was renamed to Permissions-Policy during standardization and is no longer developed under the old name. Use Permissions-Policy, which replaces it with revised allowlist syntax and adds Reporting API support.

Feature-Policy controlled access to browser features but is deprecated. Migrate its directives to Permissions-Policy, the feature names are largely the same, but the syntax differs (allowlists in parentheses rather than space-separated lists), and Permissions-Policy can report violations through the Reporting API.

X-XSS-Protection vs CSP

X-XSS-Protection is effectively dead

The browser XSS auditor it controlled was removed from browsers because it could be abused. Rely on a strong CSP instead, and send X-XSS-Protection: 0 to disable any residual legacy behavior.

The header switched on a built-in XSS auditor that had bypasses and could be turned against legitimate scripts, so Chromium removed it. Real protection comes from a CSP that blocks inline scripts: a script-src without 'unsafe-inline', using nonces or hashes, and Trusted Types.

report-uri vs report-to and Reporting-Endpoints

The reporting wiring evolved through three generations: the CSP report-uri directive (deprecated), the Report-To header (deprecated), and the current Reporting-Endpoints header. The report-to directive is now cross-browser: Chrome has supported it for years, and Safari and Firefox now support it too. Make report-to plus Reporting-Endpoints the primary wiring, and keep report-uri only to cover users on old browser versions, not whole engines. The legacy Report-To header is needed only for Network Error Logging; the full story is in Report-To vs Reporting-Endpoints.

Headers that are not superseded

Not every old header is obsolete. X-Content-Type-Options: nosniff (stops MIME-type sniffing) and Strict-Transport-Security (HSTS, enforces HTTPS) are still recommended and have no reporting-based replacement, so keep them. Note that CSP upgrade-insecure-requests complements HSTS but does not replace it; it upgrades subresource requests, not the top-level navigation HSTS protects. The two dead TLS headers with no header replacement at all, HPKP and Expect-CT, are covered in Deprecated headers.

See also

Sources

On this page