Repository navigation
[ENHANCEMENTS] WAF plugin support / Coraza integration #1297
Description
Would it be possible to extend the Zoraxy plugin system with a request/response middleware hook that would allow plugins to inspect HTTP traffic before it is forwarded to the upstream?
One interesting use case would be an optional Web Application Firewall plugin based on Coraza WAF.
Coraza is written in Go, supports ModSecurity SecLang rules and OWASP CRS v4, so it seems to be a good technical fit for Zoraxy without requiring ModSecurity itself.
Ideally, such a plugin could provide:
- enable/disable WAF per proxy rule
- OWASP CRS support
- detection-only and blocking modes
- configurable CRS paranoia level
- per-host rule exclusions
- blocked-request/event logging in Zoraxy
I don't think the WAF necessarily needs to become part of the Zoraxy core.
Providing the required HTTP request/response hooks through the plugin system could allow a Coraza WAF plugin (and potentially other security plugins) to implement this functionality independently.
Would this fit the intended direction of the Zoraxy plugin architecture?
Activity
tobychui commentedon Sep 16, 2026
Hey @roswitina
That sounds like a good security hardening feature, but the issue is that we do not have enough active maintainer to help with increasing complex feature sets. Some older features like stream proxy and certificate (SNI) manager are currently not actively maintained, which brought me worries in adding in new features.
If you wanna be the maintainer of this feature, feel free to create a pull request that adds it here (with kernel like best practice style PRs, not an AI generated huge diff, you knows what I mean 😉). I am open to discussion on Github or discord.
roswitina commentedon Sep 17, 2026
Hi @tobychui,
thank you so much for your quick and kind reply, and for being open to the idea! 😊
I completely understand your concerns about maintaining more complex features with limited resources. Unfortunately, I have to admit that I'm at best a good user, not a developer. I can't program, so I'm not able to create or maintain a pull request for this myself.
I just wanted to share the idea in case it becomes interesting for the project or for someone in the community with the right skills. If a plugin like this ever gets started, I'd be very happy to help with testing and feedback from a user's perspective.
Thanks again for all your work on Zoraxy, it's a great project! 🙏
BerziOnline commentedon Oct 1, 2026
Hi @tobychui,
I'd like to take this on and maintain it, since I need it myself (Zoraxy is the only reverse proxy in front of my self-hosted services).
The blocker for a WAF plugin today: a dynamic-capture plugin only sees the request headers, and if it accepts a request it has to answer it itself. There's no "inspect, then let Zoraxy keep proxying" path, and the body never reaches the plugin.
What I'd offer, as small, separate PRs:
I'd build a proof of concept in my fork first and run it against a test instance of my setup, then come back with PR 1 in a reviewable, kernel-style size that I can explain line by line. I'll take care of issues and follow-up on the hook and the plugin.
Would that order and scope work for you? Any preference on where the body-size limit and the fail-open/closed setting should live (per rule vs. per plugin)?
tobychui commentedon Oct 2, 2026
@BerziOnline yeah feel free to open a pull request on the plugin repo after you have a working product.