libmodsecurity3: not returning 403 on response phases

[EsadCetiner]

ModSecurity2 on Apache handles blocks for response phases by return a 403 error along with the configured 403 error page for the http server. This is not the case for libModSecurity3 where it'll instead respond with an empty response body and won't modify the response status code.

This is usually fine, but in cases like rule 950100 for CRS where the rule intends to hide the fact an 5xx error has happened, this results in unintended data leakage (The 5xx status code being returned). This behavior can also be confusing to an end user using the http server.

libModSecurity3 should respond with an http status code of 403 (Or any configured status codes) and display the configured error page for the http server.

[dune73]

Are we sure this is ModSec and not an nginx problem?

[EsadCetiner]

@dune73 Maybe, maybe not, but this is the behavior I observed.

[airween]

@EsadCetiner - thanks for the report.

Probably this is a known ModSecurity-nginx issue, see ModSecurity-nginx/41, ModSecurity-nginx/254. There was a fix in ModSecurity-nginx/326, which was merged, but later I had to rollback that patch because it didn't work if the response size was greater than 64 kB.

Could you check your log, do you have same symptoms?

[EsadCetiner]

@airween Yes, I see the same log line as everyone else

2025/11/07 04:27:42 [alert] 3051#3051: *8 header already sent while sending response to client, client: ::1, server: _, request: "GET / HTTP/1.1", host: "localhost:8080"