Same here on my installation …
Yes same here also. As far as I understand you would need nextcloud to be reachable without subfolder, so
example.org/nextcloud. So switching webserver root to nextcloud folder or copying nextcloud content to webserver root would be the solution, which would break all links and shares indeed. But according to @Oclair this is actually not more but less secure.
So I don’t know, seems there is some more discussion necessary about how so handle it best . I will leave my setup as it is, since it doesn’t seem to be a big problem.
My Server is reachable over https://cloud.example.org and only a A
I think this security scan report means the Cookie Prefixes draft.
If a cookie’s name begins with “__Host-”, the cookie MUST be:
1. Set with a "Secure" attribute 2. Set from a URI whose "scheme" is considered "secure" by the user agent. 3. 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"). 4. Sent to every request for a host. That is, a cookie named "__Host-cookie1" MUST contain a "Path" attribute with a value of "/".
Path=/ need to be set, subfolders should not work. I am not sure about the behaviour, if i.e.
index.php is shown in address field, if this also counts as path.
Also would be interesting, if __Host-cookies are set automatically, if the requirements are fulfilled or if sometimes settings need to be adjusted for that.
€: More on that from this blog post:
Same-site cookies support
The Same-site cookie support in Nextcloud 11 has been hardened even further. Same-Site cookies are a security measure supported by modern browsers that prevent CSRF vulnerabilities and protect your privacy further.
Browsers that support same-site cookies can be instructed in a way to only send a cookie if the request is originating from the original domain. This makes exploiting CSRF vulnerabilities from other domains a non-issue. Also timing attacks, such as enumerating whether a specific file or folder exists, are not feasible anymore. Nextcloud enforces the same-site cookies to be present on every request by enforcing this within the request middleware.
As hardening measure, in Nextcloud 11 we have added the __Host prefix to the cookie if the environment supports this feature. This enforces the cookie to be only sent via HTTPS and only be sent only to the host that has set this cookie. This mitigates cookie injection vulnerabilities within potential third-party software sharing the same second level domain. Note that Nextcloud does also employ regular protections against CSRF such as a shared secret between browser and client. Same-Site cookies are just considered a security hardening. More technical details about the original implementation can be read in this blog.
Okay … I had an alias in my apache2 configuration due an migration from the past …
#Alias /owncloud "/var/www/html/owncloud/" #Alias /nextcloud "/var/www/html/owncloud/"
After I commented this out … everything is fine A+
I do not have an alias or something like that in place and Nextcloud performs on NGINX.
In specific I am waiting for a solution regarding security re-scan issues.
Most probably all my issues will disappear (Nextcloud releases security scanner to help protect private clouds) because my domain is not beeing re-scanned since days.
@guddl : THANK YOU!!
That was the solution for me and I am so thankful to have this solved now. Thank you!
So to get this right:
- I also have an alias for nextcloud in conf-available actually for /nextcloud, as the folder is also in /var/www/nextcloud.
- Would the only solution be to put server root to nextcloud folder and therefore lose shares etc.?
- Or would it also be possible to put server root to /var/www, threrefore keep url/nextcloud and move all strict config and folder permissions from my alias to the ssl vhost?
I just commented out the alias
# Alias /nextcloud "/var/www/nextcloud/"
in sites-enabled, restarted the apache service and that was it.
So to compare our setups, my path is also:
and my domain is:
Before the upgrade to NC 11 connecting to my server resulted always in URLs like
NC 11 however removed the part /nextcloud/ by changes to the .htaccess I guess. I had to change nothing manually there.
From what I read about the __Host- Cookie I expected that this cannot be activated for my setup, but obviously it can.
Just try to comment out the alias and restart the webserver as well and run another security test
I have Nextcloud set up at my home. My ISP have DHCP so I have to use a DDNS from dynu.com.
My URL to access my Nextcloud is:
I don’t have any knowledge about these sorts of things on how to setup redirect, subdomain, domain, cname, virtual host and whatever ppl and guides talk about. I have just followed guides to set things up and I’m totally stupid about these sorts of things. I don’t get the “big pictures” so to say, and even how much I try to read about it I don’t understand.
I tried to comment out
Alias /nextcloud "/var/www/nextcloud/"
But then I cant connect to my Nextcloud. What do I need to do to make this work? Do I need to do some changes in dynu DDNS config, or do I need to buy a domain.
Perhaps this security flaw is not a big deal, and I can ignore it. I got an A, and maybe I should be happy I got that, but if I can do anything about it I will.
I would thankful for any help!
Hi @Eazy ,
We would need more information about your system. You are using NC 11.0.2, right? If you make changes rather go to the files in /etc/apache2/sites-enabled/. Usually there are only softlinks in this folder, but you can be sure to touch the right config file.
While there have been a lot of changes to the .htaccess file in /var/www/nextcloud with NC11.0.x you could check if the updater was able to write to that file. For me the URL I see in the browser address field changed from
with NC 11. If you still see the first kind of URL there are probably some entries in .htaccess missing.
Maybe it is better to open a new thread and post your config files there.
I am little wondering about that. Didn’t all your shares break as well as configs from external clients, mail, dav etc.? I would be reaally surprised if due to some automated changes in .htaccess the url to your nextcloud changes. This would be an extremely bad practise in my opinion as SO much depends on the url, which would need a horrible fix for every larger deployment with much users.
Hm, you’re right. Old shares and sync configurations stopped working and I had to setup every sync connection again, but while I liked the short URLs I didn’t complain.
And at least my server is now A+
To be honest I can’t rule out that I made one configuration change or two, to receive an A+. And while there were a lot of changes on the server lately (update to NC 11.0.1 and then to 11.0.2, requested improvements by users) I cannot be 100% sure, what happened only by the update and what was me. I have no change management for my small server
While writing this comment I checked my configs again and notice in the config.php:
'htaccess.RewriteBase' => '/',
I believed I added this line first after I read this thread here. Maybe this was the real reason for the changed URLs, but I have absolutely no clue.
In general I just wanted to help and describe what changed at my server, in case someone wants the A+ as bad as I did and accepts the necessity to make some config changes in the clients.
Ah yes, the changed rewrite base would make sense. This hardens my suggestion, that no sub folder is allowed for _Host prefix cookies / A+ rating.
Hmm as my nextcloud is mostly used private, I could change this without much effort. But I only have one sub domain for my server, which is given from a friends private dyndns server. So far I don’t use the web server root for any other web service/page, but this might change some day.
Ah I think I will stay with an A and keep nextcloud in a sub folder for now . If there is a way, to still get A+ with this, I would appreciate some hint .
€: Same topic and same solutions/answers here: Security: __Host-Prefix cookie setting?
So I think one of these topics could be closed ;).
Do you run nextcloud behind a reverse proxy? I am using traefik and got an A+ after adding the following line to
'overwriteprotocol' => 'https',
The secure (https) connection is terminated at the proxy and nextcloud only sees an unencrypted (http) connection coming from the proxy. As you can read in Security: __Host-Prefix cookie setting? nextcloud needs a secure (=https) connection to use __Host-cookies. So you have to overwrite the connection type
Hope that helps!
Although this topic is older than two years.
I have a similar problem and I don’t know the solution.
Can anyone help me?
This resolved my issue!!! I have NextCloud running in a docker container behind a Traefik reverse proxy… Adding this one line resolved my final issue with the ‘__Host’ prefix failing. Now I have an A+ rating!!!
I know this post is now oldoldold, but this is something I have not been able to figure out. How do I get the connection between reverse proxy and the Nextcloud container to be https? I’m using Nginx Proxy Manager and when I choose https there, I get a “502 Bad Gateway”. Obviously, something is missing at the Nextcloud end of the connection. I added your line to my config.php, but it doesn’t help. I feel like Nextcloud should be generating some kind of self-signed ssl certificate, but it doesn’t.
I got this same setup to work with the Collabora CODE container, but I just can’t get it to work with Nextcloud. Any suggestions? Anything I should add to my docker-compose, for instance?
in general it is always better you start your own thread and describe your setup, the problem, what you tried so far…
overwriteprotocol setting itself doesn’t change anything, it explicitly expected to make Nextcloud behave different. In this case you can access NC with plain http:// but it make all URL look like https://. the reason is majority of the users don’t want to use TLS behind reverse proxy - terminating TLS on your entry point (=reverse proxy) simplifies the setup - you only need to manage the complexity of certificate requests, issuing and configuring once and don’t need to replicate it to different endpoints like collabora, NC, another webservice (especially in case of docker and VMs on same physical server there is no security issues related to such setup).