I have the same problem with Nextcloud 12.0.2: either I don’t put anything special in my Apache configuration file and nextcloud is happy (and the nextcloud scanner tells me that everything is top notch) but https://observatory.mozilla.org/analyze.html?host=XXX complains that NONE of these headers is set or I set them all manually in my site.conf Apache configuration file and nextcloud complains (as well as its scanner) but observatory.mozilla.org is very happy…
I’ve of course tried with other scanners and they all follow observatory.mozilla.org as well as checked with curl and confirmed it. So I am wondering if Nextcloud’s headers are improperly set (ie in a non-standard way) or if I am doing something specially weird.
Mathias
PS: and here is my Apache configuration:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
Header always set X-Frame-Options SAMEORIGIN
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options nosniff
Header always append Referrer-Policy "no-referrer"
Header always append Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"
Header set X-Download-Options "noopen"
Header set X-Permitted-Cross-Domain-Policies "none"
</IfModule>
Yes, mod_headers is enabled (“Module headers already enabled”). I guess if it was not enabled, Mozilla’s observatory would not see my manually set headers either… What is funny is that as soon as I set them in Apache’s config file, nextcloud complains.
When I have manually set these http headers, curl -I returns (please keep in mind that Nextcloud complains that these headers are NOT SET in this case):
HTTP/1.1 200 OK
Date: Wed, 23 Aug 2017 07:29:58 GMT
Server: Apache/2.4.25 (Raspbian)
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Content-Security-Policy: default-src https: data: ‘unsafe-inline’ 'unsafe-eval’
Last-Modified: Fri, 18 Aug 2017 10:27:50 GMT
ETag: "b3-5570494bec5d3"
Accept-Ranges: bytes
Content-Length: 179
Vary: Accept-Encoding
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Content-Type: text/html
When I comment them out and only trust Nextcloud to set these headers (and then nextcloud is happy and the nextcloud scanner too), curl -I returns:
HTTP/1.1 200 OK
Date: Wed, 23 Aug 2017 07:32:49 GMT
Server: Apache/2.4.25 (Raspbian)
Last-Modified: Fri, 18 Aug 2017 10:27:50 GMT
ETag: "b3-5570494bec5d3"
Accept-Ranges: bytes
Content-Length: 179
Vary: Accept-Encoding
Content-Type: text/html
So, this really looks like something fishy on Nextcloud side… (but nextcloud scanner says that all these headers are set)
I just updated my apache2 configurations and recognized the following (NC 14.0.3):
If the apache config does not contain any X-Robots-Tag header (example, applies to all X headers) directive, Nextcloud admin panel does not complain a wrong set header, since .htaccess covers it.
If the apache config contains: Header set X-Robots-Tag "none", Nextcloud admin panel as well does not complain about this header. The old header value is simply overwritten by .htaccess anyway.
But if apache config contains: Header always set X-Robots-Tag "none", Nextcloud complains, that the header is not set correctly.
As far as I understood, headers set with “always” are added to a different table. They do not override those added with “onsuccess”, but do overwrite those without “onsuccess”.
onsuccess headers are only sent, if the request was successful, which is also the default behaviour (if non of this conditions is added) as far as I could test. A curl -D- on a non-existent resource at least does not contain any of those headers.
always headers are sent as well on unsuccessful requests.
I guess both conditional set headers do override the default (if condition met).
So, if I got it right, the always conditioned set headers will override the ones from .htaccess. But this should not lead to Nextcloud complaining, if the header values are just the same. Also a curl -D- https://my.domain.org/nextcloud then shows the correct headers as response, so Nextcloud seems to check those headers somehow wrong, or do I get something wrong?