That model has worked. It still works. But it was designed for a different era of the web — one with simple HTML forms, predictable URL structures, and a relatively small catalog of known attacks.

The web has moved on. Most WAFs haven’t.

Every Developer Knows This Pain

Before talking about WAFs, I want to talk about something more familiar.

You start with a simple check:

// Check for SQL injection patterns
if (/(\bSELECT\b|\bDROP\b|\bINSERT\b|--|;)/i.test(userInput)) {
  return res.status(400).json({ error: "Invalid input" });
}

Then you add XSS checks. Then checks for suspicious URLs. Then path traversal patterns. Then checks for repeated query parameters. Then checks for encoded payloads. Then checks for nested JSON. Then checks for GraphQL variables.

Before long, the application is filled with security-detection logic on every route, every field, every endpoint. Scattered. Inconsistent. Hard to audit.

Then you run a VAPT.

The report comes back with findings — attack vectors you didn’t cover, fields you missed, bypass techniques your regex didn’t anticipate. You go back into the codebase and patch. Add more checks. Tighten the logic.

Then the next VAPT cycle arrives. And it happens again.

This is the hidden cost that rarely gets talked about. Not a single dramatic security incident — just the slow, grinding cycle of writing security-detection logic, getting tested, finding gaps, patching, and repeating. It never fully ends, because manual detection logic spread across a growing codebase is inherently incomplete.

It’s easy to protect the login form and forget the search field. Easy to check the request body and miss query parameters, headers, or deeply nested JSON values. Easy to cover the obvious routes and leave one forgotten endpoint as the weak point.

This is one of the core problems GladiosWAF is built to address — not to replace normal application validation, but to lift the repetitive security-detection burden off application code entirely, and handle it at the layer where it belongs. So that a VAPT finding becomes an exception, not a recurring pattern.

Protecting vulnerable code before it is reached

One of the most interesting things I tested with GladiosWAF was how it behaved in front of intentionally vulnerable application code.

For example, I tested it with unsafe SQL statements that were not using parameterized queries.

In a normal application, this is dangerous. Developers should use parameterized SQL statements, proper validation, and safe coding practices. That does not change.

But the test was important because many real-world applications still contain legacy code, rushed code, old code, or forgotten endpoints where secure coding was not done properly.

GladiosWAF was able to detect and block malicious SQL injection-style requests before they reached the vulnerable code.

That matters.

It means GladiosWAF can act as a protective layer in front of applications that may not be perfectly written.

This does not mean developers should stop writing secure code.

It means GladiosWAF can reduce the risk when secure coding is incomplete, inconsistent, or missing in some parts of the application.

In many applications, the biggest problem is not that developers do not care about security. The problem is that security logic is hard to apply perfectly across every route, every field, every query parameter, every request body, and every future feature.

One missed endpoint can become the weak point.

GladiosWAF helps by inspecting requests before they reach the application, giving developers an additional layer of protection against malicious intent, even when the underlying code is not ideal.

The World Has Changed. Attack Surfaces Have Changed With It.

Modern applications are not simple websites with a few form fields.

They are API-first platforms built on JSON payloads, GraphQL queries, authentication tokens, mobile clients, third-party integrations, and increasingly, AI-generated inputs. A single endpoint might accept dozens of different payload shapes depending on the client.

That means the attack surface has expanded in ways rule-based systems were never designed to handle.

A malicious payload no longer has to look like a classic SQL injection string sitting inside a form field. It can be:

• Base64-encoded inside a query parameter
• Fragmented across multiple nested JSON keys
• Hidden inside GraphQL variables three levels deep
• Slightly reworded to avoid exact signature matches
• Placed in a header or cookie the developer didn’t think to protect

The attacker’s job has gotten easier. The defender’s job if you’re relying purely on rules — has gotten much harder.

The Real Cost of Rule-Based Thinking

Rules are not the problem. Signatures are not the problem.

The problem is that rules require you to know exactly what you’re looking for.

When an attacker uses a known payload, a well-written rule catches it. But attackers are not obligated to use known payloads. They iterate. They encode. They fragment. They generate new variants.

This creates an expensive loop: write rules, tune rules, respond to false positives, update rules when new attack patterns emerge, and repeat. For large security teams, this is manageable — they have the people, the tooling, and the institutional knowledge to keep pace.

But most development teams are not large security teams.

Most SaaS founders, backend developers, and small engineering teams just want their application to be protected. They are not trying to become WAF configuration experts. They have products to ship, customers to support, and infrastructure to maintain.

The complexity of traditional WAF management is not a minor inconvenience. It is often the reason teams skip WAF protection entirely — or deploy it in logging-only mode and never revisit it.

That gap is the problem I wanted to solve with GladiosWAF.

A Different Question

Traditional WAFs ask: Does this request match a known bad pattern?

GladiosWAF asks something different: Does this request behave like an attack?

That might sound like a small distinction. It isn’t.

The first question requires a complete and up-to-date catalog of every attack pattern you want to catch. Miss one, and it gets through.

The second question requires understanding what normal traffic looks like — and flagging requests that deviate from it in ways consistent with malicious intent.

GladiosWAF is a machine-learning-based WAF built around that second question. Instead of matching requests against a static ruleset, it analyzes the structure and composition of each request — query parameters, request bodies, JSON payloads, headers, cookies — and decides whether the overall signal looks malicious.

The goal is generalization. Not just “have I seen this exact payload before?” but “does this request look like the kind of thing attackers do?”

Why APIs Make This Significantly Harder

This is where I want to be specific, because the API security problem is often underestimated.

With a traditional web form, the attack surface is clear. There are named fields, a submit button, and a predictable request structure. A WAF can check each field against known patterns and make a decision.

With modern APIs, the structure is far less predictable. A single endpoint might accept deeply nested JSON objects, arrays of objects, optional fields, user-generated content, and dynamic query structures — all in the same request. The “dangerous” content might not be in the obvious place.

Consider a simple example:

json
{
 "user": {
   "profile": {
   "bio": "normal text here"
   }
 }
}

That looks benign. But what if bio contains an injection payload? Or what if the attacker targets a less obvious field — a metadata key, a filter parameter, a search query buried inside the request body?

Inspecting only the top-level fields is not enough. A WAF that doesn’t understand the full structure of the request is leaving significant portions of the attack surface uninspected.

GladiosWAF is designed to analyze the entire request — not just the obvious parts — and treat the payload as a whole when making its decision.

GraphQL: One Endpoint, Many Attack Surfaces

GraphQL introduces another layer of complexity worth addressing directly.

With REST APIs, different operations typically live at different endpoints:

GET /users/123
POST /login
DELETE /orders/456

The URL tells you something about what the request is doing. A WAF can use that context.

With GraphQL, almost everything goes through a single endpoint:

POST /graphql

The actual operation — whether it’s a login, a profile update, an admin action, or a search — is determined by the query and variables inside the request body. You cannot reason about what a GraphQL request is doing just by looking at the URL.

A login request and an administrative mutation may be structurally similar at the HTTP level. The difference is inside the payload.

json
{
   "query": "mutation Login($input: LoginInput!) { login(input: $input) { token } }",
   "variables": {
     "input": {
     "username": "admin",
     "password": "user-supplied value"
     }
  }
}

The value being submitted — the part that needs inspection — is nested inside variables.input.password. A WAF that only looks at the URL or the top-level request body will miss it entirely.

This is one of the areas I’ve invested the most effort in with GladiosWAF. As more applications move to API-first and GraphQL-based architectures, WAFs need to understand these request structures to remain effective.

The Part I Didn’t Expect: False Positives Are the Hard Problem

When I started building GladiosWAF, I assumed detecting malicious payloads would be the difficult part.

I was wrong.

The harder problem is avoiding false positives — blocking requests that look suspicious but are completely legitimate.

Some examples that tripped up early versions of the model:

• A developer testing their API with unusual but valid inputs
• A user pasting a long URL into a text field
• An email address containing special characters
• A deeply nested API payload that resembles injection syntax but isn’t
• A GraphQL query with complex variable structures that pattern-match against attack heuristics

A WAF that blocks too aggressively becomes a liability. Developers disable it. Users get frustrated. Logs fill with noise. The security team stops trusting the signal.

This is why tuning for precision — not just recall — matters so much in WAF design. It’s easy to block everything suspicious. It’s hard to block only the things that are actually dangerous.

A significant portion of GladiosWAF’s development has been focused specifically on this problem: learning what normal traffic looks like across different application types, so that the model can distinguish genuine attacks from legitimate-but-unusual requests.

What GladiosWAF Detects

GladiosWAF is designed to identify common web attack patterns, including:

• SQL injection
• Cross-site scripting (XSS)
• Server-side request forgery (SSRF)
• Directory traversal
• Command injection
• Obfuscated and evasive payloads
• Suspicious or malformed API request structures
• Attack patterns embedded in GraphQL queries and variables

But I want to be direct about something: no WAF is a complete security solution.

GladiosWAF is one layer of defense. Applications still need secure coding practices, proper authentication and authorization, input validation, rate limiting, logging, and good infrastructure hygiene. A WAF catches a lot — but it is not a substitute for building security into the application itself.

What GladiosWAF offers is a layer that is easier to deploy, requires significantly less manual rule management, and is better suited to the structure of modern applications.

Who This Is Built For

GladiosWAF is built for developers, SaaS founders, and small engineering teams who take security seriously but don’t have the resources to manage a complex WAF configuration.

These teams are building real applications. They have APIs, login systems, admin panels, customer data, and public-facing endpoints. Their exposure is real. But they often don’t have a dedicated security engineer, a WAF specialist, or the bandwidth to maintain a complex ruleset.

Security tooling that requires deep expertise to configure — and constant maintenance to keep effective — ends up being either misconfigured, ignored, or abandoned.

GladiosWAF is an attempt to change that equation. A WAF that adapts to modern request structures, reduces the manual configuration burden, and can be deployed by a developer team without a security specialist on staff.

Machine Learning Is Not Magic

I want to be clear about this, because the term gets misused.

A machine learning-based WAF is not a magic shield. It still requires good training data, thoughtful feature engineering, rigorous testing, and continuous evaluation. If the model is trained on poor data, it will perform poorly. If it isn’t tested against real-world edge cases, it will fail in production in ways that weren’t visible in development.

What ML offers over a pure rule-based approach is generalization. A well-trained model can recognize attack-like behavior in payloads it has never seen before, because it has learned the underlying characteristics of malicious requests — not just a catalog of specific strings.

That is the meaningful difference. Not that ML is better in every case, but that it handles novelty better than static rules can.

Where GladiosWAF Goes Next

GladiosWAF is in active development. There is meaningful work still ahead — on performance, deployment flexibility, logging and explainability, and continued reduction of false positives.

But the direction is clear.

WAFs need to become more autonomous. They need to understand the structure of modern API payloads. They need to handle GraphQL. They need to move beyond static pattern matching toward genuine behavioral analysis. And they need to become accessible to teams that don’t have a dedicated security function.

That’s what I’m building.

Not a perfect system. Not a replacement for application security fundamentals. But a smarter, more practical layer of protection for the way applications are actually built today.

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