add_header X-Frame-Options SAMEORIGIN is added somewhere in NextCloud 13

[p3x-robot]

Steps to reproduce

In the whole /etc/nginx it is only just one place where is:

if ( $x_frame_options = "") {
        set $x_frame_options "SAMEORIGIN";
}
ssl on;
#gzip off;
#add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Strict-Transport-Security "max-age=31536000; " always;
add_header X-Frame-Options $x_frame_options;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

Expected behaviour

On my server it is right and every web sites, like this:

Actual behaviour

But in NextCloud 13 somewhere it adds in itself and because it adds 2 times for sure and is not NGINX or PHP, because I can show you many pictures, that is right:

Actually, I only use in /etc/nginx so it not anywhere, I look for, and I only there in NGINX:

root@server:/etc/nginx# find -type f | xargs egrep -i x-frame-options
./default-ssl-base.conf:add_header X-Frame-Options $x_frame_options;

So only once!

Server configuration

Operating system:
Linux server 4.12.0-2-amd64 #1 SMP Debian 4.12.13-1 (2017-09-19) x86_64 GNU/Linux

Web server:
nginx/1.13.8

Database:
mariadb Ver 15.1 Distrib 10.1.29-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

PHP version:
PHP 7.2.1-1 (cli) (built: Jan 5 2018 11:21:04) ( NTS )

Nextcloud version: (see Nextcloud admin page)
13

[p3x-robot]

Actually I found this:
lib/private/legacy/response.php: header('X-Frame-Options: SAMEORIGIN'); // Disallow iFraming from other domains

[p3x-robot]

If I remove this code, then my Nginx works, but it places dual headers and it senses that my config is wrong.

[p3x-robot]

lib/private/legacy/response.php line 262. that is the bug

[p3x-robot]

This is the actual bug (i commented and now all warning removed):

[p3x-robot]

[MorrisJobke]

This is the actual bug (i commented and now all warning removed):

We don't support that this is set by the web server. The Nginx should not add this header. Fro your point in the call route we are not able to detect if it will be added by the web server or not and thus we add it there because this then needs fewer tweaking of the webserver itself.

This is thus not a bug but an enhancement to also support web servers that somehow set it.

[MorrisJobke]

See also #4605, #4863, #5246

[J0WI]

Some headers are set in PHP, some are set in .htaccess/nginx. This inconsistency is really bad.

I found them on three different locations:

server/lib/private/legacy/response.php

Lines 251 to 272 in da6c2c9

	$policy = 'default-src \'self\'; '
	. 'script-src \'self\' \'unsafe-eval\' \'nonce-'.\OC::$server->getContentSecurityPolicyNonceManager()->getNonce().'\'; '
	. 'style-src \'self\' \'unsafe-inline\'; '
	. 'frame-src *; '
	. 'img-src * data: blob:; '
	. 'font-src \'self\' data:; '
	. 'media-src *; '
	. 'connect-src *; '
	. 'object-src \'none\'; '
	. 'base-uri \'self\'; ';
	header('Content-Security-Policy:' . $policy);
	header('X-Frame-Options: SAMEORIGIN'); // Disallow iFraming from other domains
	// Send fallback headers for installations that don't have the possibility to send
	// custom headers on the webserver side
	if(getenv('modHeadersAvailable') !== 'true') {
	header('X-XSS-Protection: 1; mode=block'); // Enforce browser based XSS filters
	header('X-Content-Type-Options: nosniff'); // Disable sniffing the content type for IE
	header('X-Robots-Tag: none'); // https://developers.google.com/webmasters/control-crawl-index/docs/robots_meta_tag
	header('X-Download-Options: noopen'); // https://msdn.microsoft.com/en-us/library/jj542450(v=vs.85).aspx
	header('X-Permitted-Cross-Domain-Policies: none'); // https://www.adobe.com/devnet/adobe-media-server/articles/cross-domain-xml-for-streaming.html
	}

https://github.com/nextcloud/documentation/blob/b7dec9a1cab21cf637914073b096eeda44608f1c/admin_manual/installation/nginx.rst#nextcloud-in-the-webroot-of-nginx
https://github.com/nextcloud/documentation/blob/b7dec9a1cab21cf637914073b096eeda44608f1c/admin_manual/configuration_server/harden_server.rst#serve-security-related-headers-by-the-web-server

Things are even worse if you run NextCloud behind a reverse proxy. The headers in the PHP file are not really customizable.
I would prefer setting them only in the server config and display a warning in the setup check.

[p3x-robot]

@MorrisJobke Yeah, it says add it in NGINX, then you tell me to remove from NGINX. so which one we should use??? I think server settings is better, what do you think?

[p3x-robot]

Right now it is chaos.

[p3x-robot]

@J0WI yeah, exactly, what i mean, you cought it!

[J0WI]

From a security perspective it also makes more scene to add security settings in the server config, which is harder to hijack in the case of a possible vulnerability in the PHP app.

Edit: And the webserver is also able to set the security headers if PHP is broken for whatever reason.

[p3x-robot]

@J0WI Server is better, but if you want to use PHP, you should comment properly, i think, but of course, we cannot document, and code and fix and etc at once. So understand. I will remove the NGINX settings and I purely set it up for PHP, that's the best right? Like add modHeadersAvailable to the ENV. That's in done on PHP without NGINX or APACHE.