Cybersecurity glossary
What is X-XSS-Protection?
Learn what the X-XSS-Protection header was, why browsers deprecated XSS auditors, risks of enabling legacy filters, and what to use instead (encoding and CSP).
Definition
X-XSS-Protection is a legacy HTTP response header that enabled or configured browser XSS filters (auditors). Modern browsers have removed these filters; the header is obsolete and should not be relied on for XSS defense.
A header from another era
Browsers once shipped heuristic “XSS auditors” that tried to spot reflected attacks. Sites configured them with X-XSS-Protection. Those auditors are gone from modern engines because they were incomplete, bypassable, and occasionally harmful.
Treat this header as historical knowledge—not a control to depend on.
What the header used to configure
| Legacy value | Historical intent |
|---|---|
| 0 | Disable the XSS filter |
| 1 | Enable filter; sanitize/block detected reflections |
| 1; mode=block | Enable filter and block the page when detected |
Why auditors failed as a strategy
Bypassable heuristics
Attackers found encodings and contexts filters missed.
False sense of safety
Teams delayed real output-encoding fixes.
New side effects
Filters themselves introduced security and compatibility bugs.
Browser removal
Modern Chromium/Firefox/Safari paths no longer rely on them.
What to do instead
Fix XSS at the source
Context-aware encoding and safe HTML APIs in application code.
Deploy CSP
Reduce impact of any escaped injection bugs.
Use still-valid headers
Prefer nosniff, frame controls, HSTS, Referrer-Policy, Permissions-Policy.
Ignore auditor nostalgia
Do not design security programs around X-XSS-Protection.
- Do not treat X-XSS-Protection as an XSS mitigation requirement.
- Invest in output encoding tests and CSP adoption.
- Update legacy scanner expectations that still demand this header.
- If you must send a value for old clients, understand 0 vs 1 tradeoffs—prefer modern controls.
- Document that XSS defense is an engineering problem, not a magic header.
- Monitor real XSS findings in pentests and bug bounty programs.
- Keep secure-headers baselines aligned with current OWASP guidance.
- Educate stakeholders when dashboards still show this legacy check.
The practical takeaway
X-XSS-Protection configured obsolete browser XSS filters. It is not a modern defense. Prevent XSS with correct encoding and CSP, and keep the useful security headers that browsers still enforce.
If a checklist still demands XSS-Protection, update the checklist—not your threat model.
Related security terms
Cross-Site Scripting (XSS)
The vulnerability class this header attempted to mitigate in browsers.
Content Security Policy (CSP)
The modern browser-side control for reducing XSS impact.
Reflected XSS
The XSS type auditors tried—and often failed—to catch.
X-Content-Type-Options
A still-useful security header unlike X-XSS-Protection.
Frequently asked questions
What did X-XSS-Protection do?
It toggled built-in browser XSS filters that tried to detect reflected script patterns and block or sanitize them.
Should I still enable X-XSS-Protection?
No as a primary control. Filters are removed or unreliable. Focus on output encoding and CSP.
Why were XSS auditors removed?
They caused bypasses, compatibility breakage, and sometimes introduced new vulnerabilities—while giving a false sense of security.
What does X-XSS-Protection: 0 mean?
It disables the filter in browsers that still honor the header—sometimes recommended to avoid filter-induced issues.
What replaces this header?
Correct output encoding/escaping, safe frameworks, and a strong Content Security Policy.
Will scanners still flag a missing X-XSS-Protection?
Some legacy scanners might. Prefer modern secure-header baselines that de-emphasize this header.
References
Explore authoritative guidance and frameworks related to x-xss-protection.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.