If a scanner flags a missing x-xss security header, do not add it without checking what it does today. X-XSS-Protection is a deprecated browser filter for one narrow type of cross-site scripting, or XSS, where harmful data from the current request is reflected in the page. It is not a fix for broader WordPress security flaws.
TL;DR: Most modern WordPress sites should omit X-XSS-Protection or send X-XSS-Protection: 0. Do not add 1; mode=block just to clear an old scanner warning.
Check the public response, keep the header under one owner, and follow a broader WordPress security plan alongside a tested Content Security Policy.
What X-XSS-Protection does
An HTTP response header is a short instruction sent by the server with a page. X-XSS-Protection once told some browsers how to react when their built-in filter suspected reflected XSS.
The filter looked for harmful script in the current request and the returned page. It could remove part of the page or stop the page from loading. It ran after WordPress created the response, so it could not repair unsafe plugin or theme code.
XSS can also be stored, when harmful data is saved and shown later, or DOM-based, when browser-side JavaScript puts untrusted data in an unsafe part of a page. The old header did not cover those forms. The PortSwigger XSS overview describes the differences and the code-level defenses.
MDN marks the header non-standard and deprecated. It also warns that the filter can create security problems in an otherwise safe site. Modern sites should use a carefully tested Content Security Policy, or CSP, which lets a site limit the scripts and other resources a browser may use.
⚠️ Note: A missing X-XSS-Protection header is not proof that a WordPress site is vulnerable. It may be the correct result for a modern site.
What the old header values mean
These values still appear in scanners and older WordPress tutorials. They describe historical browser behavior, not four equally good choices today.
| Value | Historical behavior | Current guidance |
|---|---|---|
| 0 | Turned off the old browser filter. | Use when a policy requires an explicit value. |
| 1 | Enabled filtering and allowed the browser to remove parts it considered unsafe. | Do not add it by default. |
| 1; mode=block | Enabled filtering and stopped the page from rendering after a suspected attack. | Keep only for a documented, tested legacy-client need. |
| 1; report=<URI> | Enabled filtering and sent a historical report to a web address after a detection. | Do not treat it as a current reporting plan. |
The filter used guesses based on request data and page content. It could produce false positives, change safe output, or expose information through differences in page behavior. That risk is one reason current guidance favors CSP or explicit disablement.
Decide whether your site needs it
For most modern WordPress sites, do not enable the filter. A scanner warning alone is not a reason to send 1 or 1; mode=block.
- Leave the header out when no legacy requirement exists: This is the simplest modern choice.
- Send an explicit zero when your policy requires a value: X-XSS-Protection: 0 tells clients that understand the header not to use the old filter.
- Keep a legacy value only for a known client: Record the old browser or device, test the pages it uses, and remove the exception if it breaks safe content.
OWASP recommends a CSP that blocks unsafe script behavior and either omitting X-XSS-Protection or sending 0. Sending 0 does not disable CSP, safe output handling, a firewall, or malware scanning.
💡 Note: Never set 0 in one place while a CDN, server, or plugin adds 1; mode=block somewhere else. Conflicting response headers make the final browser behavior harder to diagnose.
Check the public response first
Inspect what visitors receive before editing WordPress or server files. A scanner may check only one URL, follow a redirect, or read a cached response. If the finding came from a WordPress vulnerability scanner plugin, use it as a prompt to inspect the public response, not as proof that the header is required. If WordPress reports a headers-already-sent problem, BlogVault explains the common causes and fixes in its guide to header errors.
Run a header check from a terminal:
curl -I -L https://example.com/Replace the address with your site. The -I option requests headers without downloading the page, and -L follows redirects.
Look for the final response details:
- X-XSS-Protection: Check for one value, duplicate values, or conflicting values.
- Content-Security-Policy: Check whether a CSP is already present.
- Content-Type: Confirm that the browser is told what kind of resource it received.
- X-Content-Type-Options: nosniff: Check the control that helps stop browsers from guessing a resource type.
- Status and final URL: Confirm that the response is from the page and server you intended to test.
Check the homepage and one normal content page. If you use the always option in a server rule, check an error response too.
In a baseline check of a current WordPress site running behind Nginx, the homepage returned 200 OK with Content-Type: text/html; charset=UTF-8 and no X-XSS-Protection, CSP, or nosniff header. A nonexistent query-based post returned 404, but an unknown path returned 200. This is why you should inspect the real response instead of guessing from the URL.
Save the result before changing anything. It gives you a clear comparison if a cache or delivery service hides the update.
Find the layer that controls the header
The header may be added by the web server, a CDN, a hosting panel, or a WordPress plugin. The CDN is a delivery service that can change a response before it reaches the visitor. Choose one owner whenever possible.
- Use the web server when you control Apache or Nginx: This keeps the rule close to the response source.
- Use the CDN or reverse proxy when it changes headers: A reverse proxy is a service that receives the request before forwarding it to your server.
- Use a maintained WordPress header plugin when server access is unavailable: Treat the plugin as a control panel, then verify the public response.
- Ask the host to apply the rule when access is restricted: Do not guess at a generated configuration file that the host may overwrite.
Back up before editing server settings: Keep the old rule so you can restore it. A bad .htaccess edit can cause a 500 error, which means the server cannot complete the request.
Configure it only when needed
The examples below send an explicit 0. Use a legacy value only when you have documented and tested that need.
Apache with .htaccess
Apache needs the mod_headers module, which lets it change response headers. Add this to the .htaccess server-rules file in the WordPress document root, usually a folder such as public_html:
<IfModule mod_headers.c>
Header always set X-XSS-Protection "0"
</IfModule>- Open the document root through FTP: Show hidden files, edit .htaccess, save it, and upload the changed file.
- Edit the file through cPanel: Open File Manager, find .htaccess, and use the built-in editor.
- Use SSH only when you are comfortable with server access: Move to the document root, list hidden files, and edit the file with the server’s approved editor.
If the host blocks mod_headers or file overrides, ask support to apply the rule. For a documented legacy requirement, replace 0 with 1; mode=block, then test forms, pages that use request values, and embedded content.
Apache can keep normal-response and error-response headers in separate settings. If different layers use different rules, duplicate values can appear. Check the final response rather than assuming one rule wins.
Nginx configuration
Nginx does not read .htaccess. Add the rule to the correct server or location block in the Nginx configuration:
add_header X-XSS-Protection "0" always;- Validate the configuration before reloading Nginx: Use the host’s supported test command.
- Check the block serving the domain: A more specific location or a CDN may change the public response.
- Avoid generated configuration files: Your host may replace them during the next deployment.
The always option adds the header to responses beyond successful pages. Use it only when the same policy should apply to error responses too.
WordPress header plugin
If you cannot edit the server, use a maintained WordPress security or header-management plugin that supports response headers. Check its current WordPress and PHP compatibility, choose one value, and save it in one place.
Do not follow an old screenshot blindly. Plugin labels and behavior change. A server or CDN may still control the final response, so inspect the site after saving the setting.
Verify the change and keep a rollback
Run the same response check after editing:
curl -I -L https://example.com/Confirm the change across the site:
- Check the final URL and status: Make sure redirects reach the expected page.
- Confirm one deliberate header result: The header should appear once with the chosen value, or be absent because omission was intentional.
- Compare the public response with the layer you changed: This shows whether a CDN, cache, or second plugin is rewriting it.
- Test important visitor actions: Check content pages, forms, login, payments, embeds, and admin workflows.
Purge caches when the result is stale: If WordPress changes are not showing, clear page, object, CDN, and reverse-proxy caches, then repeat the check. A browser’s private window can help confirm that you are not seeing an old local copy. Airlift’s guide to WordPress caching explains why clearing the correct layer matters.
Restore the previous setting when the site breaks: If the change causes a 500 response or breaks a feature, roll back through the supported host or plugin process. Do not add another rule to hide the problem. Find the layer that added the unwanted value and fix that owner.
Protect against XSS beyond this header
The durable fix for XSS is safe application code. Validate input, sanitize data where appropriate, and escape output for its exact context. Escaping means converting dynamic data into a safe form before displaying it. WordPress documents functions such as esc_html(), esc_attr(), esc_url(), esc_js(), and wp_kses_post() in its guide to escaping data.
A CSP gives the browser rules for which scripts and other resources may load. It is more current than X-XSS-Protection, but it is not a safe one-line WordPress setting. Themes, plugins, analytics, fonts, payment providers, embeds, and CDNs may all need different sources.
Start with report-only testing when possible: A Content-Security-Policy-Report-Only header records policy violations without blocking the page. Use those reports to find real dependencies, then tighten the policy in stages. A copied policy can break a site, while a policy that allows everything offers little protection. The OWASP CSP Cheat Sheet provides current implementation guidance.
Correct Content-Type and X-Content-Type-Options: nosniff values are useful adjacent controls. They do not replace secure WordPress code or a tested CSP.
MalCare can add another layer through a WordPress firewall plugin, which helps block suspicious traffic, plus monitoring that can detect signs of compromise. It does not replace secure theme and plugin code, context-specific escaping, CSP design, or checking which system controls the final response.
Common questions
Is a missing X-XSS-Protection header a vulnerability?
Not by itself. The header is deprecated, and current guidance may prefer omission or 0. Review the site’s code, CSP, response behavior, and other controls instead of treating an old scanner score as a complete XSS diagnosis.
What does X-XSS-Protection: 0 mean?
It tells clients that recognize the header not to use the old browser filter. It does not disable CSP, a firewall, malware scanning, or any other security control. Verify the public response after setting it.
Does 1; mode=block protect every WordPress page?
No. It was a browser filter aimed mainly at reflected XSS. It did not fix stored XSS, DOM-based XSS, unsafe plugin or theme output, or vulnerable application logic. Its pattern matching could also affect safe pages.
Why does a scanner still recommend this header?
Some scanners retain checks based on older browser guidance. Compare the finding with current MDN and OWASP guidance, then inspect the site’s CSP and other response headers.
Can a security plugin replace this header?
A security plugin can add useful protection such as malicious-traffic blocking, malware scanning, monitoring, and alerts. It cannot repair unsafe code or replace a tested CSP and correct response headers. For broader monitoring and maintenance context, see WP Remote’s guide to improving WordPress security.
Conclusion
For most WordPress sites, do not add X-XSS-Protection: 1; mode=block by default. Omit the deprecated header or send 0 when an explicit policy is useful. Reserve a legacy value for a documented compatibility need that you have tested.
The useful security work is broader and part of website hardening: inspect the final response, keep one clear configuration owner, secure WordPress output, build a CSP around real site dependencies, and verify the site after every change. A WordPress security maintenance checklist can help organize that routine work. A security plugin can add ongoing visibility and traffic protection, but it works best alongside these controls.
