server [Bug]: Setup check for `X-XSS-Protection` recommendation is deprecated

⚠️ This issue respects the following points: ⚠️

[X] This is a bug, not a question or a configuration/webserver/proxy issue.
[X] This issue is not already reported on Github (I've searched it).
[X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
[X] Nextcloud Server is running on 64bit capable CPU, PHP and OS.
[X] I agree to follow Nextcloud's Code of Conduct.

Bug description

The Nextcloud administration page shows the following warning:

The "X-XSS-Protection" HTTP header does not contain "1; mode=block". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

However, the X-XSS-Protection header is deprecated. OWASP recommends you remove the header from your webserver

It shows the following warning when the header is used:

Warning: The X-XSS-Protection header has been deprecated by modern browsers and its use can introduce additional security issues on the client side. As such, it is recommended to set the header as X-XSS-Protection: 0 in order to disable the XSS Auditor, and not allow it to take the default behavior of the browser handling the response. Please use Content-Security-Policy instead.

Steps to reproduce

Log into a Nextcloud instance as admin
Navigate towards the Administration > Overview page
Observe the recommendation of Nextcloud to set the X-XSS-Protection header

Expected behavior

Do not show this recommendation, and possibly advice users to unset the HTTP header in order to inform them of its deprecation.

Mar 09 '23 21:03 jbouter

Hi, which nc version?

Mar 09 '23 22:03 szaimen

Hi @szaimen! Version is 25.0.4

Mar 10 '23 08:03 jbouter

Related: https://github.com/nextcloud/server/issues/34748

Mar 10 '23 14:03 kesselb

I am just getting set up and am already unsetting it in my web server layer. So for me the recommendation to add it back is just obnoxious.

Instead of setting it to 0, it should simply not be set.

This is bending this issue a little bit. Remove the whole thing instead of just the warning. I wouldn't remove the in-your-face part until the underlying problem is fixed.

Adding the MDN docs to this ~

These protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline').

Warning: Even though this feature can protect users of older web browsers that don't yet support CSP, in some cases, XSS protection can create XSS vulnerabilities in otherwise safe websites.

Non-comprehensive list for removal

[ ] .htaccess
[ ] docs NGINX example configs
[ ] JS warning
[ ] dav-related
[ ] addSecurityHeaders
[ ] test-related

And also

[ ] verify the CSP is "strong enough"

Ariel,

My name is Jim I'm the project lead and chief editor for the cheatsheet project. I'd like to make the call. I've been studying this issue for a while and it's dangerous to set this header. It makes sites that are not vulnerable to XSS, vulnerable.

Scott Helme's site does not evaluate header values, it just checks if they are present. The grades it gives are highly inaccurate.

So let's change these recommendations. We have enough to make the call.

Developers need to either remove the header or set it to zero, I think the debate is over. There is NO good reason to set this header to blocking mode.

Respectfully, Jim Manico Cheatsheet Project Lead

Bold/emphasis added by me. Is there a reason this is still lingering around in the various locations listed above in this post? https://github.com/nextcloud/server/issues/37154#issuecomment-1478886601

I also searched the repo for unsafe-inline (which is generally suggested to not be used in the CSP) and noticed that it is being used throughout by some parts of NC, which is why I was hesitant to even attempt to touch this X-XSS-Protection deal, but it seems based on the above comment that the X-XSS-Protection header just really, really shouldn't be used anymore, no matter what, even if unsafe-inline is being used.

I'm going to start working on just removing it and hopefully I'll have a PR up some time in the not so distant future.

Jun 12 '25 22:06 invario

Looks a documentation PR is there since some years as well: nextcloud/documentation#9188

Jun 13 '25 21:06 iasdeoupxe

Is there any workaround to disable the warning on the admin panel for now?

Jun 27 '25 11:06 RyuKay24

Don't think so, any workaround would AFAICT require modification of core files which in turn would hide this message but would cause a new integrity check failure message.

Jun 27 '25 19:06 iasdeoupxe

My pull request #53476 is pending. Which removes the messages and checks. Feel free to give it a test.

Jun 27 '25 20:06 invario

Looks another pending PR with a different approach by @MichaIng in #53711

Jun 28 '25 08:06 iasdeoupxe

Yeah, coincidence. After sleeping a night over it, I think @invario's approach makes more sense. It is not worth the hassle to keep the check at all. Better people forget about this header. Also from security perspective, my approach is not really better, as it does not tell admin to change to the safer value (or remove the header) either, but still keeps the code for the check etc.

If we would want to tell admins to apply safest settings, we would need to check for either no header or value "0". But this will trigger a lot of tickets/topics of people asking how to do it, annoying both sides, and this is simply not worth it, IMO. The previous 1; mode=block value is not that bad either. As far as I understand, the side-channel attacks are only possible if the website can be embedded in an iframe. But Nextcloud sets/checks for X-Frame-Options SAMEORIGIN and sets CSP frame-ancestors 'self';, which prevents this on external sites. And it affects only Chromium 77 from 2019 and older, Firefox never supported XSS filtering, IE is not supported by Nextcloud since a while. ... no point to open this can of worms.

Jun 28 '25 13:06 MichaIng

Plus: There are some more relevant security headers these days which are not getting checked at all, one could argue that it is not in the responsibility of a web application to give such guidance at all (Nextcloud / ownCloud are the only one i'm aware of which are doing such suggestions).

Jun 28 '25 14:06 iasdeoupxe

Which ones do you mean in particular? Note that CSP is set be each individual Nextcloud page in PHP, the way it should be, so this is not something which can be set by the admin, without breaking things.

Jun 28 '25 15:06 MichaIng

Yes, CSP is a thing for the web app AFAICT as it needs web app knowledge to prevent breakage. 👍

But there are some more for example not checked like e.g.: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html#permissions-policy-formerly-feature-policy

(Ah, Nextcloud is setting the "old" one feature-policy instead it seems: #22792 and this didn't needed a setup check).

Also not sure about this one:

https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html#cross-origin-embedder-policy-coep

But for now focusing on getting rid of X-XSS-Protection should be fine 👍

Jun 28 '25 17:06 iasdeoupxe

Also Permissions-Policy is something that is better generated by the backend. In fact Feature-Policy is already, but it needs to be migrated. There was a start done working on this, but never finished: #23825

COOP, COEP, CORP, and in case CORS on needed remote resources, would be indeed great to have consequently implemented. Some apps will surely depend on cross-origin resources, and they would need to use CORS headers consequently for this to work. I just set this on my instance (Apache2), so far everything works fine:

Header always set Cross-Origin-Resource-Policy "same-origin"
Header always set Cross-Origin-Embedder-Policy "require-corp"
Header always set Cross-Origin-Opener-Policy "same-origin"

So all resources declare that they are only allowed to be read from documents of the same origin.
All embedded resources must set the CORP header, which we just did, or CORS.
And documents from other origins always open in a new browser context group. The other way round, also our documents declare that they must be opened in a new browser context group when accessed from documents of another origin. But that is redundant, since they also declare that they must not be read at all in that case.
Whether/from which other origins resources are permitted is controlled by CSP.

Jun 29 '25 00:06 MichaIng

[Bug]: Setup check for `X-XSS-Protection` recommendation is deprecated

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Non-comprehensive list for removal

See also