Add X-Frame-Options header to .htaccess

[J0WI]

This addresses the some major points of #8207.

This should not change the behavior of a normal request to NextCloud. But it changes the following:

Before	After
X-Frame-Options is only sent by PHP responses	X-Frame-Options is sent on all responses
security headers are only sent on 2xx responses	security headers (except dynamically generated CSP) are sent on all responses
If the X-Frame-Options header is added to the nginx example, it's sent twice for PHP responses	The X-Frame-Options header should be added to the nginx example

This should not affect installations without modHeadersAvailable.

[kesselb]

There is a setupcheck that tests x-frame-options so nginx users should see a warning after upgrade. We should add some hint to release notes about that.

[J0WI]

#4605 (comment)
I'd suggest they shouldn't use iframes or use a dedicated endpoint with a suitable .htaccess/nginx config
But I can't see a benefit if some apps are allowed to change the policy for the whole NextCloud.

[kesselb]

#4605 (comment)
I'd suggest they shouldn't use iframes or use a dedicated endpoint with a suitable .htaccess/nginx config
But I can't see a benefit if some apps are allowed to change the policy for the whole NextCloud.

I see the point of the comment but how should an app overwrite the x-frame-options with the current code?

cc @georgehrke because some calendar sharing/embedding.

[J0WI]

I think meanwhile this is done by the frame-ancestors CSP, but I didn't found a source for this.

[J0WI]

Docs are already merged.

[rullzer]

Fine by me. Altough my apache fu is rather limited.

[juliusknorr]

Makes sense, also seems to work fine to still set different headers on the Nextcloud side. 👍

[juliusknorr]

Makes sense, also seems to work fine to still set different headers on the Nextcloud side. 👍

[welcome]

Thanks for your first pull request and welcome to the community! Feel free to keep them coming! If you are looking for issues to tackle then have a look at this selection: https://github.com/nextcloud/server/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22
Most developers hang out on IRC. So join #nextcloud-dev on Freenode for a chat!

[MichaIng]

@J0WI
Might I asked for the reason to have these headers sent as well with non 2xx responses? If the request fails due to permissions, missing file or is redirected, then those headers have no practical effect, do they? For an attacker they at best provide some additional information about the webserver config and the webserver has a tiny bid more to do for 30x/40x answers.

[J0WI]

Might I asked for the reason to have these headers sent as well with non 2xx responses?

Why would you disable X-Frame-Options, XSS protection or any other security header on non 2xx responses?

For an attacker they at best provide some additional information about the webserver config

Security through obscurity is no good practice. Admins should just keep their services secure.

and the webserver has a tiny bid more to do for 30x/40x answers.

I don't think that this change has a measurable effect on performance.

[MichaIng]

@J0WI

Why would you disable X-Frame-Options, XSS protection or any other security header on non 2xx responses?

As said, because it does not have any practical effect that I am aware of, security-wise. No content is sent by the webserver with 30x/40x answers, so nothing can be done by the client where any of the headers could kick in.

Security through obscurity is no good practice. Admins should just keep their services secure.

Of course, but sending out information for no reason is as well no good practice.

I don't think that this change has a measurable effect on performance.

I agree, however I did not say that there are measurable or strong reasons to remove "always", I was just wondering what was your reason to explicitly do add it. As of above, I just see disadvantages, probably not measurable ones or deal-breakers, but I think you added it for a certain reason, any practical advantage that comes with it, and this is what I was asking for 😉.

IMO the question, before changing something, should be "why" and not "why not" 😉?