Read the request
the way your backend will.
Then decide.
RedEyes is an inline reverse-proxy web application firewall. It normalizes every request down to the form your application will actually execute, then fuses four detection engines over it. It runs entirely inside your own infrastructure.
Those three figures are not marketing. They are the thresholds our own release gate refuses to ship below — the exact commands are further down this page.
A pattern match is not an understanding.
A signature-only WAF compares your traffic against strings. Attackers know this, so they do not send the string. They send something that means the same thing to your database and nothing to the regex.
- Plain
' OR 1=1--Caught by a signature - Double-encoded
%2527%20OR%25201%3D1Pattern no longer matches - Comment-split
'/**/OR/**/1=1--Pattern no longer matches - Case + charset
%27%20oR%201%3d1%2d%2dPattern no longer matches
All four reach the same tautology at the database. A literal pattern catches the first one.
Tune it up, drown in noise
Loosen the rules to catch the variants and legitimate traffic starts getting blocked. Your team learns to ignore the alerts, which is the same as having none.
Tune it down, miss the attack
Tighten them for quiet and the encoded payload walks through. There is no static setting that is both safe and quiet.
The body is often skipped
Bodies above a size cap, unusual charsets or compressed payloads are commonly forwarded without inspection at all — past the firewall, straight into the app.
Four stages, one decision.
Not a single ruleset. A battle-tested open-source engine (Coraza / OWASP CRS) sits alongside our own normalizer, a semantic SQL/XSS parser, and a behavioural scorer — and no one of them decides alone.
Inline, in front of the app.
RedEyes terminates the connection before your backend sees it. One place to normalize, one place to decide, one place to log.
Decode to the executable form.
Multi-pass URL, HTML-entity and base64 decoding, comment stripping, charset folding and path canonicalization — repeated until the request stops changing. The detectors never see the attacker's spelling, only the meaning.
Four engines score it.
Curated signatures, the OWASP Core Rule Set through Coraza, libinjection's semantic SQL/XSS parser, and a behavioural anomaly scorer. Each returns a score, not a verdict.
Corroborate, then act.
A weighted fusion combines the scores and a corroboration gate requires agreement before blocking — so one noisy rule cannot block your customers by itself. Precise, high-confidence signatures are allowed to block alone.
Every figure here is a gate that blocks our own release.
Security vendors publish detection rates. Almost none publish the false-positive number next to it, or what happens to the build when it regresses. These are the thresholds in our CI: if a change crosses one, it does not ship — regardless of who wrote it.
| Measured | Current | Gate refuses below | Measured over |
|---|---|---|---|
| False positives | 0.00% | 0.00% | 1,121 benign requests |
| Attack detection | 100.00% | 100.00% | 244 labelled attacks |
| Blocked outright | 98.36% | 95.00% | 244 labelled attacks |
| CVE regressions | 255 cases | 100% must stay caught | 23 tracked CVEs |
| Signature coverage | 184 / 184 | every rule proven to fire | one case per rule |
1,121 benign and 244 attack cases, placed at their fused score. Two benign cases land to the RIGHT of the block line — one at 0.9072 — and neither is blocked. Score alone would have false-positived here; a block also requires corroboration: two independent detectors, or a precise signature, or the semantic parser above 0.97. That gate is what makes the rate 0.00%, not the score.
$ go run ./cmd/wafbench -corpus bench/corpus.json \
-gate -max-fp 0 -min-recall 95 -min-detect 100
FP 0.00% (max 0.00%)
block recall 98.36% (min 95.00%)
detect recall 100.00% (min 100.00%)
GATE PASSThe corpora and the gate runner ship in our development tree. The same command runs in CI and on a laptop.
There is also a ratchet: the list of known false positives may only ever get shorter. A change that adds one fails the build even if every other number improves.
What is actually on the request path.
Everything in this list is enforced in the data plane, not merely configurable in the panel. We checked.
Detection
Deep normalization
Multi-pass decode, comment strip, charset fold and path canonicalization until the request reaches a fixed point.
Hybrid fusion
Signatures + OWASP CRS + libinjection + behavioural anomaly, combined under a corroboration gate.
Request body inspection
The body is buffered within a cap and parsed the way the backend parses it — JSON, form, multipart, XML.
Virtual patching
A CVE regression corpus with a coverage ledger, so a patched class cannot silently rot back open.
Enforcement
Three modes, per site
shadow records what it would do, normal answers 403, hardened adds an IP ban. Enforcement is a per-site decision, not a global switch.
Kernel-level IP bans
A separate privileged agent applies nftables drops. The internet-facing proxy holds no elevated capability of its own.
Inspection deadline
A per-request time budget. When inspection cannot finish in time the configured fail-safe applies, and the event is recorded as such.
Rate limiting
Per-site request limits, applied before the expensive inspection stages.
Beyond the payload
Response DLP
Upstream responses are scanned for card numbers, SSNs, private keys, cloud credentials and JWTs — findings are stored redacted, never raw.
TLS fingerprinting
JA3/JA4 allow and deny lists act on the handshake, before a byte of HTTP has been parsed.
API schema enforcement
Attach an OpenAPI spec and run it off, log or enforce — only documented paths, methods and parameters are allowed through.
Audited decisions
Every verdict is logged with the evidence that produced it: which layer fired, on which normalized unit, at what score.
What RedEyes does not do.
A security product that only lists strengths is asking you to find the gaps in production. Here are ours, in advance.
No machine-learning model ships today.
Two candidate models were evaluated and both were rejected — one scored a 97.5% false-positive rate against real browser traffic. The runtime hook exists and is wired to a no-op. We would rather ship nothing than a classifier that flags your users.
Hardened mode trades precision for reach.
In hardened mode the challenge band escalates to a block. On our own benign corpus that denies 1.52% of legitimate requests while denying 99.18% of attacks. Those 17 cases are tracked individually and the list may only shrink. Normal mode remains at 0%.
The second eye is not built yet.
RedEyes is named for two eyes: one on the web layer, one on the AI/LLM layer. Only the first is in production. The second is a direction, and we will not describe it as a feature until it inspects a real request.
Some rules deliberately cannot block alone.
A handful of detections — generic command-substitution syntax, template braces — are kept corroboration-gated on purpose. They catch real attacks but overlap with legitimate content, so they contribute to a score instead of deciding. That is a choice, and it is why the false-positive number is what it is.
It runs in your infrastructure. All of it.
There is no RedEyes cloud, no telemetry on by default, and no outbound call required to protect traffic. The proxy, the dashboard and the datastores all come up inside your own network.
$ tar -xzf redeye-selfhosted-v1.3.2.tar.gz $ cd redeye-selfhosted-v1.3.2/deploy $ ./install.sh http://your-backend:8080
One command brings up the proxy, the dashboard, Postgres, ClickHouse and Redis. The dashboard binds to loopback; the proxy is the only thing that faces the internet.
Air-gap friendly
No licence server call is required to inspect traffic. An offline licence file is verified against an embedded key, and an unlicensed install still protects — licensing gates features, never protection.
Your traffic stays yours
Requests, bodies and findings never leave the machines you run. There is no vendor in the data path to trust, audit or indemnify.
Observe before you enforce
Every new site starts in shadow. You see precisely what would have been blocked, on your own traffic, before anything is.
Verified end to end
Each release is installed from the shipped archive on a clean host and driven through the real workflow — log in, add a site, confirm it reaches the data plane, turn protection on, confirm ordinary traffic still passes.
Two eyes. One gateway.
One eye on the web layer — shipping, in production, the subject of this page. One eye on the AI and LLM layer — the direction this product is built to grow into, and not yet a feature. We would rather tell you which is which.
Web security
LLM security
Self-hosted, licensed per deployment.
RedEyes is a commercial product sold directly. Tell us the shape of your deployment — how many sites, how much traffic, whether it is air-gapped — and we will quote against it rather than against a tier that nearly fits.
- All four detection engines — no capability is held back for a higher tier
- Shadow, normal and hardened enforcement, per site
- Response DLP, TLS fingerprinting and OpenAPI schema enforcement
- The dashboard, the audit trail and the live attack feed
- Signature and CVE corpus updates
- Installation support and a direct line to the engineers who built it
Put one gateway in front of everything.
Tell us what you are protecting. If RedEyes is the wrong tool for it, we will say so — that answer is cheaper for both of us than a failed pilot.