curiefense-1: Curiefense: The WAF That Thinks in Flows, Not Just Packets

A cloud-native security layer for Envoy that blends Rust, Lua, GitOps, and sequence-aware inspection into one proxy-side defense system.

8 to 10 min read • View on GitHub • More from curiefense

A fortified proxy tower stands at the center of streaming request traffic. Incoming paths split into pass, challenge, and block routes while a small Git-bound ledger guides the decision. The image explains Curiefense’s core idea: security decisions happen inside the proxy and can depend on request sequence, not just payload content. — Curiefense turns the proxy into a policy checkpoint that can judge traffic in motion, not only at the moment a single request arrives.

Key Takeaways

Curiefense’s distinctive move was to make proxy security sequence-aware, so policy could react to how requests unfold instead of treating each request as an isolated event.
Its architecture split the job across Rust, Lua, Python, Go, Redis, and Git, which let the data plane stay fast while the control plane stayed reviewable.
The project stood out because policy lived in version control, which made WAF changes auditable, reversible, and closer to application development practice.
Curiefense was influential because it pointed toward security-as-code in the service mesh, even if the project itself did not build lasting momentum.

Most WAFs ask a narrow question: does this request look bad? Curiefense asked a broader one: does this traffic make sense as a sequence? That shift is the whole project in one sentence, and it is why the repo still feels unusually modern even though it is now archived.

The project was built to live at the proxy layer, especially in Envoy and NGINX deployments. That placement matters. It lets Curiefense inspect traffic before the application sees it, which is the only practical place to combine WAF checks, bot mitigation, rate limiting, and flow-aware decisions without bolting on a pile of separate systems.

The proxy can see more than one request

Curiefense’s flow control model treats earlier requests as evidence. A login attempt, a sequence of page visits, or a path that skips expected steps can all change the judgment on a later request. That makes the system useful for abuse patterns like credential stuffing, scraping, and suspicious navigation, where the problem is not a single payload but the pattern around it.

The key insight is that Curiefense adds state as requests move through the proxy, so later decisions can depend on earlier steps in the same session.

A layered mechanical cross-section shows a request moving through stacked inspection stages. The top layer checks host and path, the middle layers tag traffic and apply filters, and the bottom layer sends surviving requests into a Redis-linked sequence tracker. The image explains how Curiefense stages cheap checks before stateful flow logic. — Curiefense narrows traffic in phases, which keeps expensive stateful checks focused on the requests that deserve them.

Why Curiefense lives in the proxy layer

The placement is the product. Curiefense runs near the edge of the system, where it can make a decision before a request reaches the app. That means it can stop bad traffic early, but it also means the engine has to be lightweight, composable, and safe enough to sit in a hot path.

That is why the repo is polyglot. Rust does the inspection core. Lua bridges the proxy integration. Python handles the control plane. Go ships logs. TypeScript and Vue power the UI. The stack looks busy because the problem is busy.

Rust does the hard part

The Rust engine is the heart of the data plane. It runs Curiefense’s staged inspection pipeline, moving a request through policy matching, tagging, content checks, and then stateful work like rate limits and flow control. The important part is not just speed. It is the shape of the pipeline: cheap decisions first, expensive decisions later.

That staging matters because proxy security lives under latency pressure. Curiefense uses asynchronous state handling so Redis-backed checks do not stall the whole path, and it keeps the decision logic organized as a state machine rather than a single monolithic filter. In practice, that makes the engine easier to reason about and easier to extend.

Curiefense is an open source project backed by Reblaze. As such, ongoing maintenance is a combined effort of the user community and Reblaze's teams.

Tzury Bar Yochay, Co-Creator / CTO at Reblaze · Curiefense FAQ

Content filtering is only one layer

Curiefense is not only a signature scanner. It combines libinjection for SQLi and XSS detection, Hyperscan for high-throughput matching, and request section omission to avoid wasting effort on trusted fields. That layered approach is the point. It lets the system cut false positives without pretending every request part deserves equal scrutiny.

The effect is practical. You can inspect aggressively where risk is high, then selectively skip content that policy has already declared safe. That is a better trade than a blunt always-on parser, especially in environments where every extra microsecond competes with throughput.

Security policy as Git history

Curiefense’s control plane is where the repo becomes opinionated. Policy is managed through Git-backed workflows, which pushes security changes into familiar software practice: review the diff, approve the change, roll it back if needed. That is a big deal for teams that do not want firewall rules trapped inside an opaque admin console.

Dimension	Curiefense	Traditional WAF	Modern cloud-native alternative
Core engine	Rust data plane with Lua integration	Mostly rule engine or module	Library, Wasm, or ML-backed engine
Where policy lives	Git-backed control plane and UI	Vendor console or local config	CRDs, declarative config, or SaaS policy
Understands request sequences	Yes, via flow control	Usually no	Sometimes, but often not the core model
Primary deployment target	Envoy and NGINX	Apache and NGINX	Ingress, service mesh, or edge proxy
Operational model	Security as code with reviewable diffs	Admin-managed rules	Mixed platform and policy workflow
Project status	Archived	Active or legacy maintained	Mostly active

Compared with a classic WAF, Curiefense is less about a giant ruleset and more about where control lives. Compared with newer cloud-native options, it is strikingly explicit about GitOps. The architecture says security policy should behave like software, not like a hidden appliance setting.

Why the project stood out, and why it stalled

Curiefense was ahead of the curve in one important way: it treated proxy security as a system design problem, not a ruleset problem. That made it unusually clean for service-mesh environments and unusually appealing to teams that wanted infrastructure and policy to share the same workflow.

But ambition does not guarantee momentum. The project was archived after maintenance and community activity faded, which is a reminder that strong architecture is not the same thing as ecosystem adoption. Curiefense helped define a direction. It did not become the default.

Based on the responses in the issue with the project, this should likely move to archive due to inactivity.

Amy Lawrence, CNCF Contributor · Health of Curiefense incubation project #1192

Project	Strength	Trade-off
Curiefense	Proxy-native, GitOps-friendly, sequence-aware	Archived, smaller ecosystem
Coraza	Active, modern WAF engine with SecLang compatibility	Less focused on flow-sequence judgment
open-appsec	Broad cloud-native security posture	More platform-centric than proxy-native
ModSecurity	Battle-tested legacy baseline	Heavier operational fit for modern meshes

The best way to read Curiefense is as a prototype of a stronger idea. It showed that a proxy can do more than filter packets. It can understand context, remember a sequence, and turn policy into versioned code. That idea has outlived the project’s active phase.