GladiosWAF 1.0 was built to answer one question: is this request malicious? For a WAF, that is the question that matters most. If a request carries SQL injection, cross-site scripting, command injection or path traversal, the priority is stopping it before it reaches the application, and nothing else matters until that part works.

But the more I tested it, the more that answer started to feel incomplete. A malicious verdict tells you something bad arrived. It doesn't tell you what it was, and that gap is what 2.0 is being built around.

From detection to classification

2.0 still has to answer the first question. When the answer is yes, it now has to answer a second one: what kind of attack is this? The vectors it is being built to separate are SQL injection, cross-site scripting, command injection, SSRF, path traversal and local file inclusion, NoSQL injection, LDAP injection and XML external entity injection.

That sounds like a labelling change. In practice it isn't. A security team looking at a blocked request wants to know why it was blocked and what the attacker was reaching for. A developer reacts differently to an SSRF attempt than to a reflected XSS attempt, and a spike in SQL injection against a single endpoint tells a different story than repeated path traversal spread across an application. Blocking is the first job. Explaining what was blocked is where a WAF starts being useful outside the request path.

The hard part wasn't adding labels

I assumed the difficulty would be teaching the model to tell the categories apart. That was part of it. The bigger part is that real payloads are messy.

Attackers don't send <script>alert(1)</script> or ' OR '1'='1' --. They encode things, change case, insert comments, use unusual separators, swap in alternative IP representations, nest expressions, and mutate a known payload until it looks nothing like the original while still meaning the same thing.

Which splits testing into two questions I had been treating as one. Did the GladiosWAF 2.0 detect it, and did it identify the right vector? A request can be blocked correctly and labelled wrongly, and adversarial testing made that obvious fast.

Red-teaming the classifier

I stopped relying on a fixed collection of payloads. An AI agent now generates campaigns new payloads, mutations, evasion chains because if I know every test case in advance, sooner or later I am just tuning the system to my own test set. Some campaigns produce straightforward attacks. Others rewrite encoding, syntax, IP format, separators or payload structure while preserving the intent underneath.

One SSRF case looked like this:

http://[::ffff:10.0.0.1]:8080/http://127.0.0.1/internal

An IPv4-mapped IPv6 address pointing into RFC1918 space, with a loopback URL appended. SSRF, clearly. GladiosWAF blocked it and called it XSS.

The defensive outcome held the request never reached the application but the label was wrong, and that is exactly the kind of failure I want the campaigns to surface.

Why the wrong label matters

It would be easy to wave this off. The attack was blocked, so who cares what it was called. I don't think that holds. Picture a dashboard showing a sudden spike in XSS when the traffic is actually SSRF probing internal infrastructure. The defence worked. The intelligence lied.

Bad labels distort attack statistics, send investigations toward the wrong part of an application, and quietly degrade every piece of analytics built on top of them. If I want GladiosWAF to produce attack data worth looking at, the labels have to be trustworthy. So 2.0 is not really about adding more rules or more categories. It is about how deterministic security logic and machine-learning classification work together.

Classification without keeping the payload

There is a second reason the label matters. GladiosWAF is designed so that it does not need to retain the request payload or the application data passing through it. Web requests carry customer records, credentials, form submissions and internal data, and a security layer that hoards all of it has solved one problem by creating another. So instead of an archive to re-inspect later, the system records that a request was blocked and what it was classified as.

That raises the stakes on getting the label right at inspection time. You can't go back a week later and re-read a payload you deliberately never kept. Classification isn't a cosmetic detail in a dashboard when the payload is gone by design, the label is most of what's left.

Understand more, store less.

Machine learning alone isn't the answer

Some attack characteristics are deterministic. A request aimed at 127.0.0.1, an RFC1918 range or a cloud metadata endpoint carries very strong SSRF signal. A well-formed external entity declaration is XXE. An LDAP filter injection has a shape of its own. When the evidence is that unambiguous, a deterministic detector should be allowed to override the model.

Pure regex has the opposite failure mode. Syntax mutates, and rules written broadly enough to catch the mutations start flagging legitimate traffic. I have spent enough time cleaning up false positives to be wary of that trade. So 2.0 is hybrid: machine learning for pattern recognition across the messy middle, deterministic logic where the signal is strong enough to trust on its own.

What the campaigns show so far

The SQL injection campaign generated 100 unique test cases across ten techniques: boolean-based injection, CASE expressions, comment and whitespace evasion, database functions, error-based injection, ORDER BY manipulation, stacked queries, subqueries, time-based injection and UNION-based injection. 57 were mutated payloads and 42 used evasion chains. All 100 detected, all 100 classified as SQL injection, no classification misses.

The XSS campaign ran 100 cases across twelve techniques: attribute breakouts, case obfuscation, event handlers, HTML entity obfuscation, iframe srcdoc, image onerror, JavaScript URIs, MathML, script tags, SVG payloads, tag fragmentation and Unicode escapes. 48 mutations, 51 evasion chains, same result.

Encouraging. Not proof. These are targeted adversarial campaigns, not evidence that every SQL injection or XSS technique gets caught. The value isn't the 100/100, it's that the test set keeps changing, which means the number can be taken away from me on any given run.

Two clean campaigns and one SSRF misclassification aren't contradictory results. The passing tests tell me which parts hold. The failing one tells me where to work.

Testing moved into the loop

The biggest change in how I build this is that adversarial testing is no longer the last step. The agent generates or mutates an attack, GladiosWAF processes it, and I check whether it was blocked, how it was labelled, and whether the label makes sense.

When something fails, I find out why. Sometimes a deterministic detector is too narrow, sometimes a pattern is too broad and starts catching legitimate requests, sometimes decoding needs to happen before classification, sometimes the model needs better training examples. Then it runs again.

That loop is worth more to me than an accuracy figure. 99% on a static dataset reads well in a slide. Attackers don't use your dataset.

Still being built

I am calling these results preliminary on purpose. 2.0 isn't finished, no adversarial campaign proves a WAF stops everything, and no WAF should claim otherwise. What the testing can show is whether the architecture is heading in the right direction, where the weaknesses are, and whether they shrink when I work on them.

I expect more misclassifications, more payloads I haven't seen before, and more assumptions I didn't know I had made. That's the point of testing this way.

1.0 asked whether a request was malicious. 2.0 asks what the attacker was actually trying to do and tries to answer it without keeping the evidence around forever.

Your WAF should understand intent, not just match patterns. GladiosWAF helps detect modern web attacks across APIs, GraphQL, headers, cookies, queries, and request bodies including evasive traffic that traditional rule-based systems may miss. Explore GladiosWAF at https://www.gladioswaf.ai