custom SecRules not honored

[sluggathor]

Using custom WAF SecRules does not block access to certain paths. Seems like the Rules are not honored - if the syntax is correct.
Using:

SecRule REQUEST_URI "@contains /admin"
"id:1001,phase:1,deny,status:403,msg:'Blocked Path',log"

in the proxy hosts WAF settings (set to merge with global) does not block access to the path (vaultwarden admin page).

WAF is enabled globally and working (generating reports and blocking).

Could someone help me out here? Tried using caddy custom pre-handlers, but can not get them to work either for blocking (403 response) access to paths.

Thank you!

[fuomag9]

I reproduced this locally and it works as expected on the current develop branch.

I added an E2E regression that enables global WAF, creates a proxy host with WAF set to merge, and uses this exact rule:

SecRule REQUEST_URI "@contains /admin" "id:1001,phase:1,deny,status:403,msg:'Blocked Path',log"

The test verifies:

• / returns 200
• /admin returns 403
• /admin?via=test returns 403

I ran:

npx playwright test tests/e2e/functional/waf-custom-path-rule.spec.ts --config tests/playwright.config.ts

Result: 4 passed

Commit: 993c0a6 (test: cover custom WAF path rule blocking)

So CPM is honoring that rule in the test stack. If it is not working in your deployment, it is likely environment-specific or Vaultwarden-specific rather than a generic CPM merge bug.

Things to double-check on your side:

• host-level WAF is actually enabled on that proxy, not just global WAF
• the host WAF mode is merge or override as intended
• you are testing the exact path Vaultwarden exposes (/admin vs /admin/)
• there is no other routing/rewrite behavior changing the request before it reaches that host

If you want, open a follow-up with your generated Caddy config for that host and I can help compare it against the passing test setup.