Hide NC URL (while sharing)

Hi, I’m using NC 12 on a shared webhosting with apache. To reduce attack surface (e.g. if I don’t manage to install updates immediately), it’s on a hidden URL, like https://example.com/ft9sXOlxlpQ/index.php etc. Now this works fine for me, but I’d like to use the “share via link” feature while still keeping my hidden URL secret, especially from the people I share links with.
Is this possible?

I already played a bit with ReverseProxy[Pass] and RewriteRule [P] in a .htaccess file in a separate location, but without success.

I imagine a separate URL on the same host (like https://example.com/share/asdf ) which would display the content of the sharing-link https://example.com/ft9sXOlxlpQ/index.php/s/..., but without revealing the ft9sXOlxlpQ part.

You could come up with some kind of rewriting scheme, but you would need an index to keep track of all the associations between

asdf -> ft9sXOlxlpQ

You could perhaps write an app doing this for you. But your Nextcloud setup will still be available in public and from the download interface, an attacker can still suppose you have Nextcloud installed, and to guess your real URL (of your NC setup) is quite obvious. Not of your sharing link, but this is accessible via proxy (and if there is a possible attack you must be sure that your proxy filters these kind of attacks).

of course, but that shouldn’t be a problem for the low number of shares I’m using/about to use.

Yes, the exposed sharing interface is still susceptible to attacks, I’m aware of that.

Can you explain how my real NC URL should be obviously guessable? As I said, it should not be revealed by anything in the proxied sharing/download page.

In your example, you use the same domain name. You might also take a look on the proxy-things, especially when you pass through commands that this doesn’t generate an error revealing the hostname.

There was an Owncloud app called “Shorten” for that purpose. Here is the repository:

It uses a configurable URL shortening service to create share links without exposing the real domain of the server. Maybe somebody is interested in making it compatible with Nextcloud and putting it on the store.


I have no problem revealing the hostname, it’s public anyway. I don’t want to reveal the path to the nextcloud installation (ft9sXOlxlpQ in the example above). By using a subdomain instead of a subdirectory this would be the same, but then I’d reveal the NC subdomain in my TLS certificate (until Let’s Encrypt has wildcard certificates).

So to clarify:

@alfred Thanks for that link, however if I read the code correctly, shorten just forwards (HTTP redirect) the client to the actual share url, which again leaks my NC path.

I think I do not understand why you want to do this. If there is a security problem with Nextcloud, the URL of your NC setup will be potentially enough for an attacker. What special threat do you see in a sharing link? And especially a sharing link accessed directly but which will be safe to be accessed through a proxy?

What is your use case?

that’s why that “URL of my NC setup” shall remain hidden, from everybody except me.

seems we’re misunderstanding each other intensely here.

Ok, I see, sorry your initial post was clear enough. Security through obscurity is not the best approach: https://en.wikipedia.org/wiki/Security_through_obscurity

It’s hard to think of everything and your real URL could be leaked (html-headers, error message, invitation messages, …). Proper solution would be to make such a rewriting scheme, but bind Nextcloud to a local network on your server. And you connect through a VPN to this network, so that it is technically impossible to connect to NC directly.

Personally, I think such a model could protect you from drive-by attacks (just checking default subfolder names of domains, …) but once someone has his hands on your rewrite domain and invests enough time, I wouldn’t be so sure if there is no way around.

Other idea: use a different NC setup only for public shares, you can link some folders from your private setup as read-only. Or put such content on a common external storage to avoid any direct link.