Protecting NextCloud behind CloudFlare Firewall and Anti-DDoS

For convenience, most NextCloud instances are running on a web server exposed to the Internet, and its myriad of cybercriminals and security threats. Even if your NextCloud server is properly hardened and all your users have 2 factor authentication switched on, it’s still vulnerable to port scans and vulnerability probing that can effectively result in a DoS (denial of service) attack. Putting NextCloud behind a managed security service such as CloudFlare can mask the true IP address of your NextCloud server (or load balancer) reducing your attack surface. CloudFlare’s WAF automatically blocks bad requests from attackers’ bots which can easily saturate your server’s log files with 404 (Not Found) and 403 (Forbidden) errors for commonly exploited paths to web applications (commonly WordPress and phpMyAdmin) – some of which you might not even have installed.

Best of all, CloudFlare has a basic, free plan that can be adequate to protect most NextCloud instances. Upgrading to the Pro plan ($20/mo) or above gives you access to the latest set of WAF rules as soon as CloudFlare’s security team publishes them across their network. CloudFlare relies on hosting your entire DNS zone with their service, so your entire second-level domain ( where you host NextCloud must be configured for CloudFlare – even if you are using a subdomain such as ( A workaround can be to use an entirely separate second-level domain for NextCloud, if your organization does not want to transition web/email services to a new DNS provider.

CloudFlare does not necessarily prevent uploading large files > 100 MB to the NextCloud instance, as large file uploads are chunked and buffered by NextCloud automatically. It’s a common misconception that you need to upgrade to the Enterprise plans to increase the file size limit, since data is uploaded in 10MB chunks and joined together on the server. However, CloudFlare does impose a request timeout of 100 seconds which can be reached if your storage backend has a slow I/O speed. Our team of NextCloud and CloudFlare experts can help you configure NextCloud for large file uploads behind the CDN and WAF.

The recommended NextCloud web server (Apache or Nginx) configuration files include Content Security Policy Headers which prohibit the loading of unsafe scripts from a different origin – this is a best practice that helps prevent XSS (Cross Site Scripting) attacks. By default, CloudFlare’s performance features such as Rocket Loader minify and rewrite scripts on your applications, and serve them from

The problem is is considered a different origin than your NextCloud instance URL – so the Content Security Policy takes effect and blocks the required JavaScript from loading (hampering the functionality of your NextCloud web interface). Even if you relax the Content Security Policy to allow loading scripts from, CloudFlare’s performance features will not work because the nonce (hash) for the script generated by Rocket Loader changes from time-to-time.

Refused to load the script '' because it violates the following Content Security Policy directive: "script-src 'nonce-c1lJZVBOUE0xeWpheE4rYmlFYkg2UG5RWEFUdGwrclJsdW1ERjhrQnJ6MD06MXRodGE2ZXVwRTJNdk9qWC9CYjJnS09IUFUrVTVhaXIvNS82Ui81TDQybz0=' blob:". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

Create CloudFlare Page Rule for NextCloud URL

  • Cache Level – Bypass
  • Disable Performance – Performance is disabled

The most reliable approach is to create a CloudFlare Page Rule to exclude the NextCloud domain/subdomain from Performance features (including Rocket Loader) and set the Caching level to Bypass. You would still benefit from faster load times as a result of CloudFlare’s extensive network of Points of Presence (PoPs) around the world, and of course, the DDoS Protection and Security features remain in effect.

Disable Email Masking by CloudFlare (to make NextCloud Federation Cloud IDs in web interface visible)