Same question here. I’m guessing it’s automagically enabled when the environment supports it, but a quick google can’t find anything about which part of my environment is unsupported.
Note that this is only a “hardening” but not a security vulnerability per se. So if you don’t manage to have it: It won’t make your data insecure, but having it is an easy small security gain
Can you check if those conditions are met for you? If yes and the setting isn’t applied this could be a bug or a misconfiguration in your setup. Send me a PM with your domain then please and I can check that
I guess the second point explains it for me. I have https://mydomain.net/nextcloud
(/var/www/nextcloud/)
But why doesn’t it work with subfolders and is there a way to enable __Host-Prefix anyway? If I have to get rid of the subfolder, does it mean I have to move /var/www/nextcloud/ to /var/www/
If a cookie’s name begins with “__Host-”, the cookie MUST be:
Set with a “Secure” attribute
Set from a URI whose “scheme” is considered “secure” by the user
agent.
Sent only to the host which set the cookie. That is, a cookie
named “__Host-cookie1” set from “https://example.com” MUST NOT
contain a “Domain” attribute (and will therefore be sent only to
“example.com”, and not to “subdomain.example.com”).
Sent to every request for a host. That is, a cookie named
“__Host-cookie1” MUST contain a “Path” attribute with a value of
“/”.
As per item 4 this means that we cannot do much here. That said, not having this security hardening doesn’t put you at risk. But it is something that you can consider for a future deployment.
If you really want to have an A+ rating here the easiest way would be to change the DocumentRoot in the apache configuration. However, all your connected clients would need to be reconnected and sharing links would stop working.
@LukasReschke so the rating considers a nextcloud installtion more secure, if it runs directly in the root of a webserver where the crawlers find it, instead of running it in a “hidden” subdirectory?
Re-reading what @LukasReschke wrote and re-checking my configuration, I’m coming to think that the issue is not the folder in which we placed our nextcloud installation but rather the subdomain.
I just realized that although having NC installed in /var/www/nextcloud/
it reads https://cloud.mydomain.net/index.php
So I guess it meets the criteria for path="/".
However he also mentions that there can’t be a sub-domain. And maybe someone can help with that, because I’m pretty new to web servers and cloud and stuff:
How can I achieve not having NC under a sub-domain?
I rent a domain at 1und1.de and while I don’t have a static IP address I think I had to create a sub-domain and enter the My-Fritz URL (like dyndns.org) as CNAME.
As said, being a newbie, what can I do different to get the A+?
Every advise and detailed explanation by the experienced users is very welcome and really appreciated.
Administrators are encouraged to install Nextcloud on a dedicated domain such as cloud.domain.tld instead of domain.tld to gain all the benefits offered by the Same-Origin-Policy.
This is a bogus security suggestion. Always link a cloud to another subdirectory where search engines do not pry! I give the nextcoud security checker an A- for suggesting it is more secure to host the cloud on the root of a published DNS entry!
Just thought I would add my A+ rating solution here in case others have a similar setup to myself. I found this thread when I used the Nextcloud scanner and achieved an ‘A’ rating, good, but no cigar! I was presented with the __Host-Prefix issue and the fact that the scanner detected my installation was in a sub-folder (/owncloud), which it wasn’t, it was being served from https://mynonwww.domain.co.uk. In addition I was running NC 11.0.1.
I did much searching around without much success for the __Host-Prefix issue solution. In the end it was simple. Upgrading to 11.0.2 fixed the __Host-Prefix issue.
As for the NC installation in a sub-folder. I had migrated from OC9 to NC. After some searching around in my apache config I discovered I had a legacy owncloud.conf file in /etc/apache2/conf-available/. This in turn contained a directory alias for a /owncloud /var/my/OC-NC-installation. As this was not in use, I simply removed the alias from the owncloud.conf file (I’m confident this conf file can be removed safely in the long-term for most migrated installations (just rename it to something else like owncloud.conf.[date])).
Re-ran the NC scanner…A+ rating.
I hope this helps someone else who has a similar setup.
Those looking to get an overall measure of how their server security is stacking up might want to also use:
this