[HELP] Nextcloud Calendar won't load fully: OPTIONS /remote.php/dav/principals/users/myuser/ gets 400 not reported by UI

[LeoChaser]

What happened?

Browse to Nextcloud Calendar, but it doesn't load calendars nor events.
Should load everything as expected.
OPTIONS /remote.php/dav/principals/users/myuser/ gets 400 not reported by UI, even though OPTIONS is allowed.

Calendar loads fine with USE_MODSECURITY disabled.

How to reproduce?

Browse to Nextcloud Calendar.
nextcloud-aio-nextcloud version: 33.0.5.1 calendar: 6.5.0.
USE_MODSECURITY enabled

Configuration file(s) (yaml or .env)

IS_DRAFT=no
SERVER_NAME=example.com
USE_TEMPLATE=low
BAD_BEHAVIOR_THRESHOLD=30
BAD_BEHAVIOR_BAN_TIME=3600
CORS_ALLOW_ORIGIN=*
USE_CROWDSEC=yes
KEEP_UPSTREAM_HEADERS=*
CONTENT_SECURITY_POLICY=
REFERRER_POLICY=no-referrer-when-downgrade
PERMISSIONS_POLICY=
COOKIE_FLAGS=
AUTO_LETS_ENCRYPT=yes
EMAIL_LETS_ENCRYPT=e-mail@example.com
LETS_ENCRYPT_CHALLENGE=dns
LETS_ENCRYPT_DNS_PROVIDER=cloudflare
USE_LETS_ENCRYPT_WILDCARD=yes
LETS_ENCRYPT_PROFILE=shortlived
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM=cloudflare_api_token snip
LIMIT_CONN_MAX_HTTP1=25
LIMIT_CONN_MAX_HTTP2=200
LIMIT_CONN_MAX_HTTP3=200
LIMIT_REQ_RATE=15r/s
ALLOWED_METHODS=GET|POST|HEAD|OPTIONS|PUT|DELETE|PATCH|PROPFIND|PROPPATCH|REPORT|MKCOL|COPY|MOVE|LOCK|UNLOCK
MAX_CLIENT_SIZE=1g
USE_REAL_IP=yes
REAL_IP_HEADER=CF-Connecting-IP
REAL_IP_FROM_URLS=https://www.cloudflare.com/ips-v4/ https://www.cloudflare.com/ips-v6/
USE_REVERSE_PROXY=yes
REVERSE_PROXY_SSL_SNI=yes
REVERSE_PROXY_HOST=http://sub.example.com:11000
REVERSE_PROXY_WS=yes
USE_ROBOTSTXT=yes
ROBOTSTXT_COMMUNITY_LISTS=ai-robots-txt robots-disallowed

Relevant log output

ModSecurity: Access denied with code 400 (phase 2). Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/nginx/example.com/server-http/modsecurity-rules-global-crs.conf.modsec"] [line "14"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "XML parsing error: XML: Failed to parse document."] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "example.com"] [uri "/remote.php/dav/principals/users/myuser/"] [unique_id "snip"] [ref "v1360,1"]

BunkerWeb version

1.6.11

What integration are you using?

Docker

Linux distribution (if applicable)

No response

Removed private data

• I have removed all private data from the configuration file and the logs

Code of Conduct

• I agree to follow this project's Code of Conduct

[TheophileDiot]

Hi @LeoChaser,

The block here isn't the OPTIONS method. Your log shows the request was denied by rule 200002 ("Failed to parse request body" / "XML parsing error: XML: Failed to parse document"). Nextcloud's DAV endpoints send XML bodies for calendar and contacts sync, and ModSecurity's request-body parser is rejecting them, so the 400 happens regardless of the method. That is also why it works with USE_MODSECURITY disabled, and why having OPTIONS in ALLOWED_METHODS makes no difference.

This is a well-known Nextcloud tuning case, not a method problem. A few ways to handle it, from least to most invasive:

1. Enable the Nextcloud CRS exclusions (recommended)

The CRS team maintains a Nextcloud exclusions plugin. You already have USE_MODSECURITY_CRS_PLUGINS on by default, so just add:

MODSECURITY_CRS_PLUGINS=nextcloud-rule-exclusions

This is exactly what our official Nextcloud example uses: https://github.com/bunkerity/bunkerweb/blob/master/examples/nextcloud/docker-compose.yml

2. Or start from the community Nextcloud template

There is a community-maintained Nextcloud template with WebDAV-aware defaults in the bunkerweb-templates repo: https://github.com/bunkerity/bunkerweb-templates/tree/main/templates/nextcloud

It gives you a vetted baseline tuned for this kind of sync traffic. To use it, upload the template from the web UI on the Templates page (or drop the directory into a plugin's templates/ folder), then set USE_TEMPLATE=nextcloud instead of low. Worth opening its template.json first to see the exact settings and configs it applies. The template mechanism is covered under "Concepts > Templates" in the docs.

3. If the 400 persists, drop rule 200002 for the DAV path only

Rule 200002 is a base body-parse rule rather than a CRS rule, so the exclusions above may not fully cover it. If calendars still fail, add a custom modsec config that removes only 200002 for /remote.php/dav, keeping body-parse protection everywhere else. Easiest via the web UI (Configs > Create new custom config, type modsec):

SecRule REQUEST_URI "@beginsWith /remote.php/dav" \
    "id:1599,phase:1,t:none,nolog,pass,ctl:ruleRemoveById=200002"

The id just needs to be unique among your rules. Custom config types and methods are documented under "Advanced usages > Custom configurations".

A couple of notes:

• If you ever switch on USE_MODSECURITY_GLOBAL_CRS, CRS plugins are not loaded, so you would rely on option 3 in that case.
• On the "not reported in the UI" part: ModSecurity blocks normally show on the Reports page with a Resolve button, so if this 400 isn't appearing there, it may be a separate reporting gap. We'll confirm that internally, since it's distinct from the calendar loading.

Could you try option 1 (or option 2) and let us know if calendars and events load? That tells us whether the targeted 200002 rule in option 3 is also needed.

[LeoChaser]

Hello, @TheophileDiot,
Thank you for your detailed response, I'm debugging my configurations. I've gone through the 2nd option, but the web calendar app won't load yet even though there are no more 400 errors. But the real problem is: when I work with this Nextcloud behind Traefik, it loads fine. Mind you that all of these are in my homelab, and I have other "services" behind Bunkerweb, so I didn't go with first option because I think I'd have to setup another separate Bunkerweb exclusively for this Nextcloud I'm running. Since it's getting late here, and I'm going to work early tomorrow, I'll quit for today, and try the first option later.
Thank you again.

[Simonmiz]

Hi there @LeoChaser

I had the exact same Nextcloud issue

It also affects Nextcloud Tasks

What i did was to implement the modsec exclusion for that specific path, thats what worked for me and is running stable currently

[LeoChaser]

Was testing option 2 and as @Simonmiz said, Tasks is also affected, besides Calendar and Contacts. With SECURITY_MODE=detect it won't report, only log (200002 related Warning), but Bunkerweb won't report nor log anything related to those with blocking setting on. Tried creating a rule excluding 200002 for the DAV path only as @TheophileDiot stated, and it didn't work either for the service nor globally. I've even tried updating my compose file to 1.6.12 version of Bunkerweb.

Console errors:
Calendar
[ERROR] calendar: [Vue error]: Error in https://vuejs.org/error-reference/#runtime-bm: TypeError: can't access property "split", a is undefined
Contacts
Uncaught (in promise) TypeError: can't access property "split", i is undefined
Tasks
TypeError: can't access property "split", t is undefined

All of those errors won't show on SECURITY_MODE=detect as everything loads nicely. Next I'm gonna try first option as @TheophileDiot recommended.

[Simonmiz]

Hi there,

The solution on my end was the Nextcloud Bunkerweb Template which has the CRS Exclusions enabled by default, and a custom modsec-crs rule that removes 200002 under a specific path

SecRule REQUEST_URI "@beginswith /remote.php/dav/principals/users/" "phase:1,nolog,pass,id:10050,ctl:ruleRemoveById=200002"

Are you using the Nextcloud Template with such an modsec rule?