March 7, 2026

How We Took WAFBench SQLi Detection from 37/46 to 46/46

Security testing fails quietly when payload delivery is wrong. A benchmark can look comprehensive while still missing the conditions a WAF actually inspects.

The `0.3.46` through `0.3.54` release arc was a sustained hardening pass on MockForge bench security testing. The work was not about adding a bigger payload catalog. It was about getting transport semantics right: distributing payloads across VUs, applying them to generated requests, handling cookie jar behavior correctly, grouping multi-part CRS cases together, decoding form and URI payloads properly, and delivering path and body attacks in the formats WAF rules expect.

What changed

• `0.3.46` improved attack coverage by distributing payloads across VUs and honoring custom headers in OWASP API tests.
• `0.3.47` and `0.3.43` ensured security payloads were actually injected into generated k6 requests.
• `0.3.48` through `0.3.52` fixed cookie handling, accepted all CRS payloads, and grouped URI, header, and body payloads into single realistic requests.
• `0.3.53` and `0.3.54` refined URI encoding, form handling, and path injection semantics for better CRS rule inspection.

Why this matters

A WAF benchmark is only trustworthy if payloads are delivered in the same shapes and locations a real attack would occupy. When cookies collide, grouped attacks split apart, or form bodies arrive in the wrong encoding, the result is a misleading score. These releases corrected those details so security test results better reflect real request inspection.

The engineering lesson is straightforward: security tooling is often won or lost in request semantics, not just payload count. MockForge’s WAFBench hardening work was about fixing the harness until the benchmark meant something.