| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
…strict test config
…rvention-handling-in-modsecurity-nginx Phase 4: configurable handling, content-type scoping and JSON logging
…igs-and-document-phase-4-functionality docs: add bilingual Phase-4 handling docs and example configurations
…n-modsecurity-proxy Guard allocations, tighten phase4 content-type parsing, and update tests
…nability-issues-in-modsecurity-nginx Reduce nesting and split declarations to address SonarQube maintainability issues
…in-src/ngx_http_modsecurity_body_filter Fix SonarQube issues in body filter (split declarations, reduce nesting)
There was a problem hiding this comment.
This PR adds configurable Phase 4 response-body intervention handling for the ModSecurity nginx connector, including safer late-intervention behavior, scoped content-type handling, structured logging, and related tests/docs.
Changes:
Copilot reviewed 17 out of 17 changed files in this pull request and generated 11 comments.
Show a summary per file| File | Description |
|---|---|
| src/ngx_http_modsecurity_module.c | Adds new Phase 4 directives, config parsing, defaults, and intervention metadata capture. |
| src/ngx_http_modsecurity_common.h | Extends request/location config structs for Phase 4 state. |
| src/ngx_http_modsecurity_body_filter.c | Implements Phase 4 scope checks, late-intervention handling, and JSON logging. |
| tests/modsecurity.t | Enables strict mode for existing Phase 4 baseline tests. |
| tests/modsecurity-h2.t | Enables strict mode for HTTP/2 Phase 4 tests. |
| tests/modsecurity-proxy.t | Enables strict mode and adds in-scope proxy backend responses for Phase 4 triggers. |
| tests/modsecurity-proxy-h2.t | Enables strict mode for HTTP/2 proxy Phase 4 tests. |
| tests/modsecurity-phase4-regression.t | Adds large-response minimal-mode regression/logging coverage. |
| tests/modsecurity-phase4-modes.t | Adds mode behavior and JSON-line logging tests. |
| tests/modsecurity-phase4-invalid-config.t | Adds intended invalid content-type config coverage. |
| tests/modsecurity-phase4-content-types.t | Adds content-type scoping behavior tests. |
| docs/phase4-handling.en.md | Documents English Phase 4 behavior, modes, logging, and limits. |
| docs/phase4-handling.de.md | Adds German Phase 4 behavior documentation. |
| docs/examples/phase4-minimal.conf | Adds minimal-mode production example. |
| docs/examples/phase4-safe.conf | Adds safe-mode production example. |
| docs/examples/phase4-strict.conf | Adds strict-mode production example. |
| docs/examples/phase4-content-types.conf | Adds example scoped content-type list. |
src/ngx_http_modsecurity_module.c:659
n = ngx_read_file(&file, buf, ngx_file_size(&fi), 0);
ngx_close_file(file.fd);
if (n < 0) return NGX_CONF_ERROR;
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Sorry, something went wrong.
| } | ||
| location /phase4 { | ||
| modsecurity on; | ||
| modsecurity_phase4_mode strict; |
|
Excellent PR, thanks @Easton97-Jens! Please take a look at Copilot's suggestions. I think it would be great to add some minimal description about the new directives to main README. Other than that, I would like to test this PR locally, and play with it for a wile - I need some time for that. Thanks again. |
Sorry, something went wrong.
…pilot-comments-for-pr-#377 Address Copilot review feedback for phase‑4 handling
…-new-nginx-directives docs: document phase4 nginx directives in README
|
Sorry, something went wrong.
|
Thanks! The only remaining thing is one Copilot suggestion that I currently can’t apply cleanly without changing behavior, so I left it as-is for now. Take your time testing the PR locally, and let me know if you find anything or have more feedback 🙂 |
Sorry, something went wrong.
|
https://github.com/Easton97-Jens/ModSecurity-test-Framework I split out a small evidence/test framework that runs the same YAML-derived cases through real Apache and NGINX connector paths. It currently verifies ARGS, ARGS_NAMES, REQUEST_BODY, REQUEST_COOKIES, REQUEST_HEADERS, FILES, XML, AUDIT_LOG, RESPONSE_HEADERS, etc. RESPONSE_BODY remains xfail/mapped-only, and RAW argument collections are mapped-only with the current local v3 source because the ARGS_RAW family is not present there yet. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
What changed
This PR introduces and stabilizes dedicated phase:4 handling for the nginx ModSecurity connector.
Main additions include:
Additional fixes included in this PR:
Why these changes
phase:4 operates on response bodies. At this stage, nginx may already have sent response headers or even part of the response body.
Because of this technical limitation, actions such as:
cannot always be converted into a clean client-visible HTTP response once headers are already sent.
This PR introduces explicit and predictable handling for those late-intervention scenarios:
→ downgrade to log_only
→ downgrade to log_only (default-safe production behavior)
→ optional connection_abort
The goal is to:
Logging and observability
The new phase4 logging implementation provides structured JSON-lines logging including fields such as:
Tests also verify that response-body payload data is not leaked into phase4 logs.
Testing
This PR adds and extends coverage for:
Documentation
Comprehensive documentation for the implemented behavior was added, including: