[WAF] The WAF breaks the EventSource (SSE) compatibility

[abriand-solicis]

Version

v1.4.8

What happened?

I use Beszel to monitor several machines; when the WAF is active on the host, the web client is unable to establish a EventSource connection (SSE).
I think this issue is similar to the #10 .

Expected behavior

Even if the WAF is active, having the ability to connect to EventSource.

Steps to reproduce

1. Have a Beszel instance
2. Enable the WAF on the Beszel instance
3. After the activation, when going to the web hmi, the web client stuck when calling the /api/realtime eventsource (SSE)

Relevant logs

Deploy method

Docker Compose

[marcoome]

Thanks for the report - reproduced with a local Beszel 0.19.0 hub behind the same caddy:2.11.4 + coraza-caddy v2.5.0 pins as the edge image, driven by headless Chrome.

What is actually happening

The EventSource itself is fine: GET /api/realtime returns 200 and streams PB_CONNECT through the WAF on both HTTP/1.1 and HTTP/2. What breaks is the next step. The PocketBase SDK registers its subscriptions with POST /api/realtime, and that body contains topics such as systems/*?options=.... CRS rule 942100 (libinjection SQLi) reads the /* as a SQL comment, the anomaly score reaches the blocking threshold, and the POST gets a 403. The SDK then reconnects and retries forever, which in devtools looks like a stuck /api/realtime request.

This only happens with the WAF in blocking mode. In detection-only mode nothing is blocked and the dashboard works.

Workaround on v1.4.8

On the Beszel host, under WAF → extra directives, add:

SecRuleRemoveById 942100

and save so the node is re-pushed. Verified in blocking mode: subscriptions return 204 and the dashboard updates normally.

Fix in #15

The panel's "suppress rule" action only hid events from the WAF Events page and never reached the node config. After #15, suppressing a rule (globally or per route) emits SecRuleRemoveById on the affected routes and re-pushes every node, so this becomes a one-click fix from the events page. docs/WAF.md also documents the PocketBase/Beszel case.

[abriand-solicis]

Hello,

I tried the workaround and attempted to disable blocking mode, but nothing works.
The only thing that works is completely disabling the WAF on the host.

[marcoome]

You are right, and my first diagnosis was incomplete - sorry for the runaround. Reopening until the fixed edge image is in a release.

What I missed

There were two separate bugs. The 942100 false positive from my previous comment is real, but it only bites in blocking mode. The one you are hitting is lower down: coraza-caddy 2.5.0, which the v1.4.8 edge image is built with, forwards Flush() through a plain http.Flusher type assertion. Caddy wraps the response writer in a recorder whenever access logging is on - and HPG turns access logs on for every node - and that recorder only exposes flushing via Unwrap(). Every flush got dropped, so the SSE response never even sent its headers. That is why blocking vs detection-only made no difference and why only disabling the WAF (which removes the wrapper) helped. My earlier repro ran the route without the node's access-log config, which is exactly the condition that hides it.

Re-verified with the real generated node config, caddy:2.11.4 and a Beszel hub in headless Chrome: with 2.5.0 the /api/realtime GET stays pending forever; with 2.6.1 it connects and subscriptions return 204.

Fix

#17 bumps the edge image to coraza-caddy 2.6.1, which carries the upstream fix (corazawaf/coraza-caddy#344, "flush and hijack through the response writer Unwrap chain"). No config change on your side - the node just needs the new image.

How to get it now

The edge tag was rebuilt from main with that change (release run 35144381895). In your compose .env:

IMAGE_CADDY=ghcr.io/host-yt/caddy-proxy-manager-edge:edge

then docker compose pull caddy && docker compose up -d caddy and re-enable the WAF on the Beszel host. It will land in v1.4.9 as the default image; I will note here when that is tagged.

If you run blocking mode, keep the SecRuleRemoveById 942100 directive as well - that part of the earlier comment still applies.

[abriand-solicis]

The applied fix works perfectly, thanks!