Fix: Remove X-XSS-Protection use, check and recommendation

[invario]

• Resolves: #37154

Summary

Use of the X-XSS-Protection header with value "1; mode=block" is deprecated and in fact it appears to generally be recommended against. There are indications that from searching online that using it may actually cause vulnerabilities.

TODO

Test for any issues? I put this PR together quickly by just searching the repo for any mention of X-XSS-Protection and removing it/the corresponding code. There were a total of (8) instances located and I removed them all in this PR.

If simply removing this is bad practice, I would appreciate input/direction, as from what I read, the proper solution is to implement a "strong" CSP. One of the suggestions to avoid problems is to ensure unsafe-inline isn't used, but when I spot checked various NC apps and pages, I saw it was being used.

**However**, I believe it is still recommended to remove X-XSS-Protection no matter what.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• [ ] Tests (unit, integration, api and/or acceptance) are included
• [ ] Screenshots before/after for front-end changes
• [ ] Documentation (manuals or wiki) has been updated or is not required
• [ ] Backports requested where applicable (ex: critical bugfixes)

[iasdeoupxe]

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

[invario]

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

Thanks! I didn't even look into the documentation yet, but now that I searched, it seems there are (3) instances of it being mentioned in the docs. (2) of them are for nginx sample configurations, and (1) is the one you mentioned. I'll gladly do another PR to remove those mentions... but wondering if I should wait to see if my current PR gets a green light.

[MichaIng]

Umm, coincidentally I was just annoyed enough by the false warning and created as well a PR to address this 😅. It however leaves the check in place, just allows 0 to be an accepted value as well, and suggests it, since this is the last well-known recommendation: #53711 And to not cause a ton of issues/topics on forum GitHub, I also allowed the old value to remain.

But OWASP indeed suggests both, either disabling XSS filtering explicitly, or not setting the header at all. So removing it from checks entirely is probably the better move. But I will leave the PR as alternative, if someone prefers it that way.

For anyone who is interested in more details about this header, and the actual vulnerabilities XSS filtering causes, even if combined with page blocking:

• MDN web docs give some explanation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-XSS-Protection#security_considerations
• The OWASP cheat sheet recommends 0, or not setting the header at all: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html#x-xss-protection
• Here the related discussion when this recommendation was updated: https://github.com/OWASP/CheatSheetSeries/issues/376
• A Stack Overflow question underlines the clear recommendation, adding some more details: https://stackoverflow.com/questions/9090577

[github-actions[bot]]

Hello there, Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[MichaIng]

@invario can you rebase please, so we get checks green? I did locally, so there are no conflicts, but better to keep your commit signature. We need to wait for vacation lock to be lifted anyway, but lets assure everything else is finished and ready, to minimize any further delay.

I updated https://github.com/nextcloud/documentation/pull/9188 to match this PR.

[invario]

@invario can you rebase please, so we get checks green? I did locally, so there are no conflicts, but better to keep your commit signature. We need to wait for vacation lock to be lifted anyway, but lets assure everything else is finished and ready, to minimize any further delay.

I updated nextcloud/documentation#9188 to match this PR.

Great, thanks! Will rebase. Need bit of time. limited Internet on cruise lol

[nickvergessen]

From: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-XSS-Protection#security_considerations

though this approach might be vulnerable to side-channel attacks if the website is embeddable in an

But that is basically exactly it. By default Nextcloud is not embeddable from anywhere but itself: https://github.com/nextcloud/server/blob/af6de04e9e141466dc229e444ff3f146f4a34765/lib/public/AppFramework/Http/ContentSecurityPolicy.php#L75-L78 But reading further it seems CSP is covering this in general and for more browsers (comments against it were from 12-15y ago before CSP was a wide-spread thing).

[MichaIng]

But that is basically exactly it. By default Nextcloud is not embeddable from anywhere but itself:

Right, and even if CSP is not supported, it sets (and checks for) X-Frame-Options. So the side channel attacks possible with 1; mode=block are probably not possible on Nextcloud if everything else is correctly configured. Either way, no point to enforce anything in either direction: 1; mode=block, 0, and not defining the header at all should all be fine.

[nickvergessen]

Tests are weirdly failing.

[MichaIng]

Cypress and performance tests are expected to fail, but no idea what the background of this is:

Can not run cypress on forks

Can not run performance tests on forks

[nickvergessen]

That is not what was confusing, the background is security of our GitHub tokens. No-DB unit tests however were failing with something unrelated that is discussed in another PR to be added. Let's see if it passes here now.

[MichaIng]

Ah right, secrets are not accessible by forks, so Cypress would then fail due to empty CYPRESS_RECORD_KEY, unless that is added to the fork.

But why was the performance test failing, or why shall it not run on forks? Regarding secrets, it uses ${{ secrets.GITHUB_TOKEN }} only, which is set by GitHub and always available. Could be actually replaced by ${{ github.token }}, which is exactly the same, but makes more clear that it is not really a secret.

However, nodb tests and everything else is green.

Suitable for backport to 31 and 30 or not?

[iasdeoupxe]

Not sure who is responsible so posting just here for now, https://scan.nextcloud.com probably needs adjustments as well as it reports e.g. the header as missing now.

[MichaIng]

Good point! Not sure where to report best 🤔.