Nextcloud aims to ship with secure defaults that do not need to get modified by
administrators. However, in some cases some additional security hardening can be
applied in scenarios were the administrator has complete control over
the Nextcloud instance. This page assumes that you run Nextcloud Server on Apache2
in a Linux environment.

Note

Nextcloud will warn you in the administration interface if some
critical security-relevant options are missing. However, it is still up to
the server administrator to review and maintain system security.

Nextcloud uses the bcrypt algorithm, and thus for security and performance
reasons, e.g. Denial of Service as CPU demand increases exponentially, it only
verifies the first 72 characters of passwords. This applies to all passwords
that you use in Nextcloud: user passwords, passwords on link shares, and
passwords on external shares.

Nextcloud uses a RFC 4086 (“Randomness Requirements for Security”) compliant
mixer to generate cryptographically secure pseudo-random numbers. This means
that when generating a random number Nextcloud will request multiple random
numbers from different sources and derive from these the final random number.

The random number generation also tries to request random numbers from
/dev/urandom, thus it is highly recommended to configure your setup in such
a way that PHP is able to read random data from it.

Note

When having an open_basedir configured within your php.ini file,
make sure to include /dev/urandom.

Nextcloud is able to generate preview images of common filetypes such as images
or text files. By default the preview generation for some file types that we
consider secure enough for deployment is enabled by default. However,
administrators should be aware that these previews are generated using PHP
libraries written in C which might be vulnerable to attack vectors.

For high security deployments we recommend disabling the preview generation by
setting the enable_previews switch to false in config.php. As an
administrator you are also able to manage which preview providers are enabled by
modifying the enabledPreviewProviders option switch.

Using Nextcloud without using an encrypted HTTPS connection opens up your server
to a man-in-the-middle (MITM) attack, and risks the interception of user data
and passwords. It is a best practice, and highly recommended, to always use
HTTPS on production servers, and to never allow unencrypted HTTP.

How to setup HTTPS on your Web server depends on your setup; please consult the
documentation for your HTTP server. The following examples are for Apache.

To redirect all HTTP traffic to HTTPS administrators are encouraged to issue a
permanent redirect using the 301 status code. When using Apache this can be
achieved by a setting such as the following in the Apache VirtualHosts
configuration:

While redirecting all traffic to HTTPS is good, it may not completely prevent
man-in-the-middle attacks. Thus administrators are encouraged to set the HTTP
Strict Transport Security header, which instructs browsers to not allow any
connection to the Nextcloud instance using HTTP, and it attempts to prevent site
visitors from bypassing invalid certificate warnings.

This can be achieved by setting the following settings within the Apache
VirtualHost file:

We recommend the additional setting ;preload to be added to that header.
Then the domain will be added to an hardcoded list that is shipped with all
major browsers and enforce HTTPS upon those domains. See the HSTS preload
website for more information. Due to the policy
of this list you need to add it to the above example for yourself once you
are sure that this is what you want. Removing the domain from this list could take some months until it reaches
all installed browsers.

This example configuration will make all subdomains only accessible via HTTPS.
If you have subdomains not accessible via HTTPS, remove includeSubdomains;.

Default SSL configurations by Web servers are often not state-of-the-art, and
require fine-tuning for an optimal performance and security experience. The
available SSL ciphers and options depend completely on your environment and
thus giving a generic recommendation is not really possible.

As Nextcloud supports features such as Federated File Sharing we do not consider
Server Side Request Forgery (SSRF) part of our threat model. In fact, given all our
external storage adapters this can be considered a feature and not a vulnerability.

This means that a user on your Nextcloud instance could probe whether other hosts
are accessible from the Nextcloud network. If you do not want this you need to
ensure that your Nextcloud is properly installed in a segregated network and proper
firewall rules are in place.

Basic security headers are served by Nextcloud already in a default environment.
These include:

X-Content-Type-Options:nosniff

Instructs some browsers to not sniff the mimetype of files. This is used for example to prevent browsers from interpreting text files as JavaScript.

X-XSS-Protection:1;mode=block

Instructs browsers to enable their browser side Cross-Site-Scripting filter.

X-Robots-Tag:none

Instructs search machines to not index these pages.

X-Frame-Options:SAMEORIGIN

Prevents embedding of the Nextcloud instance within an iframe from other domains to prevent Clickjacking and other similar attacks.

These headers are hard-coded into the Nextcloud server, and need no intervention
by the server administrator.

For optimal security, administrators are encouraged to serve these basic HTTP
headers by the Web server to enforce them on response. To do this Apache has to
be configured to use the .htaccess file and the following Apache
modules need to be enabled:

mod_headers

mod_env

Administrators can verify whether this security change is active by accessing a
static resource served by the Web server and verify that the above mentioned
security headers are shipped.