Good job… I was pretty sure it had something to do with that .htaccess.
DarkSteve mentioned it before. Do not use both.
Have a nice day!
Uh, wat?
The ability to update Apache should not be tied to the version of the OS you’re using. That’s incredibly bad design. If your OS limits your ability to update the software on it, it’s a very bad OS.
That’s absolutely atrocious. How do you tell what version of the software your on? How do you tell what patch level you’re running? Does this apply only to Apache? To Samba? To Dovecot? To PHP? To what extent? How do you know what version you’re really running of any software if the version numbers are meaningless?
If you’re running a “patched” version of the old Apache 2.4.10, can you tell? What if you’re not running a patched version of Debian? Can you tell whether Apache 2.4.10 is secure or not? That is a terrible way of managing software.
I ran into the same problem as others on here and was kind of getting annoyed with it but I found the solution for my problem.
In my case, the message kept appearing due to the Header setting being added multiple times.
I had the header line in my .htaccess, apache.conf and in my nginx.conf (found that out by checking my URL on securityheaders.com)
I removed the header entry from the .htaccess and the apache.conf because my website is only accesible via HTTPS, so the line should only be in the nginx.conf
1 Like
After upgrading to 14.x using nginx I had to update header.conf with nano:
nano /etc/nginx/header.conf file
Deleted the line below by adding a ‘#’ in front of:
#add_header Referrer-Policy “same-origin” always;
Added:
add_header Referrer-Policy no-referrer always;
Exit nano
Restart nginx service:
service nginx restart
And the message disappeared. All checks passed.
1 Like
I also have:
The “Referrer-Policy” HTTP header is not set to “no-referrer”, “no-referrer-when-downgrade”, “strict-origin” or “strict-origin-when-cross-origin”. This can leak referer information.
But I’m using shared host and manage all from cloudflare:
What to choose ? is this OK ?
So that I can remember for the future, here is what I did to correct this problem (I am running Ubuntu 16.04):
-
In /var/www/html/nextcloud/.htacess, I commented out: Header set Referrer-Policy "no-referrer"
-
In /etc/apache2/apache2.conf, I have the following:
<IfModule mod_headers.c>
Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
Header always set Referrer-Policy "no referrer"
Header always set Referrer-Policy "strict-origin"
</IfModule>
This removes the warning.
I hope that this is helpful to someone.
I run a Raspberry Pi with ubuntu based linux.
Til 14.04 I used following config line:
Header always set Referrer-Policy “no-referrer”
This raised an security error.
I changed it to:
Header set Referrer-Policy “no-referrer”
Warning went away.
EDIT. Just checked it with Qualys:
Happy 
I just tried that but it didn’t get me the A+. Which config file did you modify?
Sorry if I’m mistaken, but AFAIK the ssltest from Qualys doesn’t refer to the header settings and only checks the SSL configuration regarding key exchange, cipher strength and so on like seen on the score bars in the screenshot.
For a real header configuration test you should navigate to the already linked site https://securityheaders.com/
@voidoid3 there are guides for a good SSL configuration out there.
So simplified it’s mainly about disabling weaker ciphers and stronger key encryptions.
Actually removing the setting from Apache2 Vhost for Nextcloud solved the issue for me.
As it’s already set in .htaccess with 14.0.4 the check will fail if it’s set twice.
I might be wrong though, but it solved the issue for me at least.
4 Likes
Thanks @Schmu. I’m still learning. At this point, I have an A rating with the following issue:
Content-Security-Policy This policy contains ‘unsafe-eval’ which is dangerous in the script-src directive.
Searching but not finding how to address this.
Hi,
We are all still learning and there is no stop for that in the IT 
Regarding the unsafe-eval:
There is nothing you can do about that right now. This is a CSP setting which is required by Nextcloud itself or rather most of the NC apps.
The developers are aware of that and try to remove all functions which require eval in the code, but it takes time.
However they already implemented a small solution which drastically reduces the risk of that setting and therefore there should be no or hardly any danger.
Don’t worry about it
As long as everything else of your header settings are fine, your site is preloaded with https and your ssl settings are good, you are pretty safe.
1 Like
You are absolutely right.
For headers you should use check mentioned by you.
Did that and received an A.
Do someone know what to add to solve the “Feature-Policy” thing?
For “Feature-Policy” I added the following line to my nginx config (server block):
add_header Feature-Policy "accelerometer 'none'; autoplay 'self'; geolocation 'none'; midi 'none'; notifications 'self'; push 'self'; sync-xhr 'self'; microphone 'self'; camera 'self'; magnetometer 'none'; gyroscope 'none'; speaker 'self'; vibrate 'self'; fullscreen 'self'; payment 'none'; usb 'none'";
You can and should adjust that to your needs
If you are aiming for A+: this won’t be possible due to the unsafe-eval. I’m capped with A as well.
Hello everyone,
I just wanted to post an update and let you know that the “unsafe-eval” Content Security Policy has been removed in NC15. So right now we can even receive an A+ at securityheaders.com
If you want to run a more complete test, I even suggest to go to:
https://observatory.mozilla.org/
It has a more detailed overview for CSP as well.
In case you wonder about a few missing CSP entries for your server, I reported that at Github already:
With my configuration changes I reached a score of 120/100
The current maximum possible score is 135 out of 100.
So 15 points still missing to the absolute maximum, but “unsafe-inline” for style-src policy is still lowering the score.
I think I read somewhere, that style-src “unsafe-inline” comes from certain apps which haven’t been updated to the new NC directives. So this will be improved in the feature in any case.
1 Like
Reached A+ at security headers as well with NC 15.
Did not change any code and got 110/100 at mozilla.
My result looks like this:
How about yours?
My guess is that some apps may hit the score.
Im getting 110/100 with the exact same recommendations.
Maybe is the web server configuration.
As mentioned, I made some changes to my configuration, in order to get a better score.
I changed the web server configuration and added an additional CSP header for “Feature Policy” in my nginx config:
add_header Feature-Policy "accelerometer 'none'; autoplay 'self'; geolocation 'none'; midi 'none'; notifications 'self'; push 'self'; sync-xhr 'self'; microphone 'self'; camera 'self'; magnetometer 'none'; gyroscope 'none'; speaker 'self'; vibrate 'self'; fullscreen 'self'; payment 'none'; usb 'none'";
This change should be pretty safe and I believe this can be recommended. In case someone integrated other services and sites, which require some of these features, the configuration needs some adaption of course to allow ‘self’ and the other service/ site.
And in addition I changes one PHP file of Nextcloud to force the usage of the CSPs which are reported to be missing on the testing site: frame-ancestors and form-action.
Strangely “frame-ancestors” is actually defined in the PHP code, but somehow it doesn’t end up in the header. I reported this as probable bug on Github already:
So just to have a complete explanation what I did, here it is, but use with caution and be aware that it might cause some apps to stop working (haven’t discovered any so far).
So in /var/www/nextcloud/lib/public/AppFramework/Http/EmptyContentSecurityPolicy.php I added a new line for the policy for “form-action” here:
public function buildPolicy() {
$policy = "default-src 'none';";
$policy .= "base-uri 'none';";
$policy .= "manifest-src 'self';";
$policy .= "form-action 'self';";
Farther down below I added a few “else” blocks:
if(!empty($this->allowedFrameDomains)) {
$policy .= 'frame-src ' . implode(' ', $this->allowedFrameDomains);
$policy .= ';';
}
else {
$policy .= "frame-src 'self' https://office.mydomain.tld https://www.draw.io;";
}
if(!empty($this->allowedChildSrcDomains)) {
$policy .= 'child-src ' . implode(' ', $this->allowedChildSrcDomains);
$policy .= ';';
}
if(!empty($this->allowedFrameAncestors)) {
$policy .= 'frame-ancestors ' . implode(' ', $this->allowedFrameAncestors);
$policy .= ';';
}
else {
$policy .= "frame-ancestors 'self';";
}
if (!empty($this->allowedWorkerSrcDomains)) {
$policy .= 'worker-src ' . implode(' ', $this->allowedWorkerSrcDomains);
$policy .= ';';
}
else {
$policy .= "worker-src 'self';";
}
This works for me to improve my CSP headers, but I wouldn’t recommend this changes to everybody. The else blocks are rather dirty hacks, because I don’t know exactly where and why the headers are not added to the policy.
I hope this explains it enough now
2 Likes