Security check results wrong, SSL labs checks A+

Entering the Admin settings, I get multiple lines that indicate missing X-… lines. Even when using the nextcloud security check I get wrong results.
And on others clouds even the results from the nextcloud check and other checks differ.
The strange thing is that those lines that are discovered by other checks as SSL Labs and give no error warnings.

I’ve setup Nextcloud in various configurations. One config is on a subdomain only with other IPv4 and IPv6 addresses. Entering the requested code in .htaccess or the config.php in Nextcloud does not work. I used:

Header always add Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header set X-Content-Type-Options “nosniff”
Header set X-XSS-Protection “1; mode=block”
Header set X-Download-Options “noopen”
Header set X-Permitted-Cross-Domain-Policies “none”
Header set Referrer-Policy “strict-origin”
SetEnv modHeadersAvailable true
Header always set X-Frame-Options “SAMEORIGIN”
Header always set Content-Security-Policy “default-src https: data: ‘unsafe-inline’ ‘unsafe-eval’”

And this should normaly be working, as far as i’ve experienced so far.

Why are all those settings not used by ??

What im i missing?


If you check here and on the bugtracker for the homepage (, you will see that there are a few issues with this scanner that are way more basic that they need to be fixed first.
I’d rather suggest to put a link to the ssl and x-frame-options scanner on (feel free to submit a bug report for that).

The admin settings do not see the server configuration, for such things it is better to run a scan with an external scanner. Even in the admin menu, it could perhaps a bit clearer and link to documentation where we could link such scan-services. If you want to suggest improvements for the admin-page, this goes into the server repository (

I get these results from


ok X-Frame-Options
x X-Content-Type-Options
x X-XSS-Protection
x X-Download-Options
x X-Permitted-Cross-Domain-Policies

Scanning with SSLlabs : A= on IPv4 and IPv6. No errors.

Scanning with the X-fram options header tool Geekflare

Strict-Transport-Security max-age=31536000; includeSubDomains; preload
Content-Security-Policy default-src https: data: ‘unsafe-inline’ ‘unsafe-eval’
Referrer-Policy no-referrer strict-origin
Feature-Policy autoplay ‘self’;camera ‘none’;fullscreen ‘self’;geolocation ‘none’;microphone ‘none’;payment ‘none’
X-Frame-Options SAMEORIGIN
X-XSS-Protection 1; mode=block 1; mode=block
X-Content-Type-Options nosniff nosniff
X-Permitted-Cross-Domain-Policies none none

They are all OK except Public-Key-POins and Expect-CT (orange)

In the table you posted it looks like all headers except x-frame-options contain the value twice. You could verify this using the browser console. The scanner does not appear to be broken in general, as it does not report any issues for me.

The actual problem is that NC does not check if settings exist.
We put the security settings on the domain level for all our customers in DirectAdmin, httpd settings.Since multiple clients are on the same IPv4 and IPv6 addresses, we do not them to weaken security.

The sollution is simple but still not implemented by NC.
In htacces they should use “ifset” and not “set”. By this there will be no doubling and thus the certancy that it works. That is not the case with the default htacces that NC writes.