Why I Built GladiosWAF: I Was Tired of Writing the Same Security Code Over and Over

GladiosWAF started from a specific frustration: rewriting the same security validation logic across every new project and every new stack. This is the founder's honest account of why that repetition is a real security risk, why rules alone aren't enough, and what a more intelligent reusable WAF layer is actually trying to solve.

There was a specific moment that pushed me over the edge.

I was building a new project — a fairly standard SaaS with a login form, an API, and a few admin endpoints — and somewhere around midnight, I found myself writing the same input validation logic I had already written several times before on different projects.

Same intent. Different stack. Different syntax. Same tired feeling.

It was not a dramatic security incident. Nobody got hacked. Nothing urgent happened. And I thought to myself:

What if I could build a AI WAF that could help me protect the website?

That question is basically where GladiosWAF started.

It started from a very practical developer frustration: I was tired of rewriting the same security checks again and again, and I started to realize that repetition itself could become a security problem.

The Repetition Problem Nobody Talks About

When developers talk about web security, the conversation usually goes straight to named attacks.

SQL injection. Cross-site scripting. Server-side request forgery. Command injection. Directory traversal. Broken access control.

Those threats are important. But what gets discussed less is the maintenance cost of defending against them in real projects.

Every new project needs validation. Every new form needs validation. Every new API endpoint needs validation. Every new request body needs validation. Every new query parameter needs validation.

And every time you build something new, you have to think through the same security concerns again.

Is this input safe? Can this field be abused? Should this query parameter exist? Can this URL become an SSRF issue? Can this value be used in SQL? Can this input become XSS? Can this request body be manipulated?

At first, this feels ok. Anyway, validation is part of software development right.

But after doing it across multiple projects, the pattern becomes hard to ignore.

You are not solving the problem once. You are solving the same class of problem repeatedly, in slightly different forms.

Different Stacks Make the Problem Worse

The problem compounds when you work across different technology stacks.

I have built things in Node.js, Python, and .Net. The security thinking is usually similar, but the code is not portable.

The middleware is different. The request object is different. The routing system is different. The validation library is different. The way you access query parameters is different. The way you inspect request bodies is different.

So even when the intention is the same, the implementation changes.

In one project, you may write validation inside Express middleware. In another, you may use a Python validation library. In another, you may handle it through .NET request handling. In another, you may need to inspect JSON or GraphQL differently.

The security concern does not disappear. It just changes shape.

And because every stack requires a slightly different implementation, developers like myself ends up rebuilding similar defensive logic again and again.

I can lived with repetitiveness but the question is what if I miss it?

The more times you spent manually rewrite the same kind of security logic, the more chances there are to miss something.

You may protect one form but forget another. You may validate the request body but miss the query string. You may protect the login endpoint but forget an admin endpoint. You may handle SQL injection patterns but miss SSRF-style input. You may get it right in one stack and implement it differently in another.

And sometimes, you make mistakes simply because you are tired. That is real life.

Security does not fail only because developers do not care. Sometimes it fails because the same work has to be repeated so many times in so many places.

What I Actually Wanted

I did not start by thinking, "I want to build a WAF."

A lot of WAF marketing can feel overwhelming — big claims, large rule libraries, complex dashboards, and systems that still require constant tuning.

What I wanted was simpler, something that I don't even need to write any rules.

I wanted a reusable layer that could sit in front of an application and inspect incoming requests before they reached my code.

Something that could look at a query parameter, a JSON payload, a form input, or an API request and say:

This looks normal. Allow.

Or:

This looks suspicious. Block.

Without me having to rewrite the same detection logic from scratch for every project.

The way I thought about it was simple. My application code should focus on business logic.

Can this user access this record? Is this order valid? Is this email address already taken? Does this account have permission? Should this workflow continue?

Those are application-specific questions. Only the application can answer them properly.

But there is another kind of question:

Does this request look like it is trying to do something malicious?

That is a question commonly being asked.

It should not have to be reimplemented from scratch every time a new project is built. And that became the idea behind GladiosWAF.

GladiosWAF Started as a Reusable Security Layer

GladiosWAF was built from a developer's frustration with repeated security work.

Instead of writing similar security checks again and again across different projects, I wanted a reusable inspection layer that could analyze incoming requests before they reached the application.

The goal is not complicated:

Inspect the request early. Allow normal traffic through. Flag or block suspicious traffic before it reaches the application code.

This does not replace validation inside the application.

It reduces the amount of repeated security detection logic that has to be manually rebuilt in every project.

For example, your application should still validate that an email field contains a valid email address. It should still check that a user has permission to access a resource. It should still enforce business rules.

But suspicious input detection should not always have to be rewritten from zero.

If a request contains signs of SQL injection, XSS, SSRF, command injection, directory traversal, obfuscation, or suspicious API behavior, it makes sense to inspect that before the request reaches deeper application logic.

That is the role I wanted GladiosWAF to play. Not the only layer. But a useful layer in front.

Why Rules Alone Were Not Enough

The obvious solution to this problem is a rule-based WAF.

Block known patterns. Maintain a list of bad signatures. Stop anything that matches.

Rules are useful. I am not dismissing them.

If someone sends an obvious SQL injection payload, it should be blocked. If someone sends a clear XSS payload, it should be blocked. If someone tries a known path traversal pattern, it should be blocked.

Rules are fast, understandable, and effective against known patterns.

But modern attack traffic is not always that clean.

Attackers encode payloads. They obfuscate strings. They split payloads across parameters. They hide values inside JSON. They place suspicious content inside GraphQL variables. They probe slowly. They change inputs slightly until something slips through.

Against this kind of traffic, a static ruleset has limits.

Not because rules are useless.

But because attackers are often trying specifically to avoid matching them.

That is what pulled me toward machine learning as part of the approach.

Not as a magic solution.

But as a way to look at request characteristics more broadly.

Instead of only asking:

Does this match a known bad pattern?

I wanted the system to also ask:

What does this request actually look like?

How is it structured? How long is it? What characters does it contain? Is it encoded? Does it contain suspicious combinations? Does it resemble known malicious behavior? Is the overall shape of the request unusual?

This is a harder problem. But it feels closer to the right question.

What GladiosWAF Is Not

I want to be honest about this because I think security products lose trust when they oversell themselves.

GladiosWAF is not a magic fix for every security problem inside an application.

If an application stores passwords in plain text, skips authorization checks, exposes sensitive records without checking ownership, or allows users to access data they should not see, those are application-level security problems. They must be fixed inside the application.

A WAF does not automatically know every business rule.

It does not automatically know that only User A should be allowed to view Invoice B.

It does not know whether a user should be allowed to approve a refund, change another user's role, download a report, or update another customer's record.

That kind of logic belongs inside the application, and it always will.

Where GladiosWAF helps is different.

GladiosWAF is designed to detect suspicious intent before the request reaches vulnerable code.

That includes SQL injection attempts, XSS payloads, command injection patterns, traversal attempts, SSRF-like requests, and other risky inputs.

In my demo application, I intentionally used an unsafe SQL statement to test this exact scenario. The point of the demo is not to recommend unsafe SQL. The point is to show that GladiosWAF can still reduce risk even when vulnerable code exists behind it.

That matters because many real applications are not perfect. Some are legacy systems. Some were built quickly. Some contain old patterns that are hard to replace immediately.

GladiosWAF is meant to help narrow that exposure.

It is a useful defensive layer before dangerous input reaches vulnerable code.

Not the only layer.

Not a replacement for application security.

But an extra layer that can make vulnerable applications harder to exploit.

Who This Is Actually For

Large companies often have security teams.

They may have people dedicated to tuning WAF rules, reviewing logs, responding to alerts, and managing security infrastructure.

That is not the only audience I had in mind.

I built GladiosWAF thinking about developers and small teams.

The developer building the frontend, backend, database schema, deployment pipeline, and security checks at the same time.

The SaaS founder who needs to ship features but also has a public login page and API exposed to the internet.

The small team without a dedicated security engineer, but still facing real attack traffic.

These teams still need protection.

They still deal with SQL injection attempts. They still deal with XSS payloads. They still deal with SSRF probes. They still deal with command injection attempts. They still deal with directory traversal attempts. They still deal with suspicious API requests.

But they may not have the time, budget, or expertise to constantly write, tune, and maintain security logic across every project.

Those people need something practical.

Something that does not require a week of configuration before it becomes useful.

Something that fits into how developers actually build applications.

That is the itch GladiosWAF is trying to scratch.

The False Positive Problem

One thing I underestimated early on was how much false positives matter.

It sounds obvious in hindsight, but being too aggressive can become its own problem.

If a system blocks too much normal traffic, developers will stop trusting it.

They may turn it off. They may bypass it. They may ignore the alerts. They may treat it as noise.

And once that happens, the security tool has failed in a different way.

Real users do unusual things.

Someone may submit a long message through a contact form. Someone may paste code into a text field. Someone may include special characters in a legitimate search query. A developer may test an API with JSON that looks strange but is valid. A technical user may submit a URL that is perfectly normal in context.

Not all unusual input is malicious. That distinction matters.

The hard part is building a system that can better separate:

Unusual but acceptable input.

From:

Suspicious and potentially malicious input.

That requires more than simple keyword matching.

It requires looking at multiple signals together.

That is one of the most interesting engineering challenges in GladiosWAF.

Where GladiosWAF Is Going

GladiosWAF is still evolving. There are rough edges. There are things I am still improving. There are decisions that still need testing in real-world environments.

But the direction is clear.

I want GladiosWAF to become a reusable inspection layer that works across different stacks and helps developers reduce repeated security work.

A layer that can inspect incoming requests before they reach application code.

A layer that can help identify suspicious traffic earlier.

A layer that can reduce the need to manually rebuild the same detection logic project after project.

And just as important, a layer that does not create so much noise that developers abandon it.

The goal is not to be the only thing standing between an application and the internet.

That would not be realistic.

The goal is to be a useful, intelligent first line of inspection — one that helps catch suspicious traffic early, reduces repeated security work, and makes application security less dependent on manually rewritten checks.

Why I Built This

If you have ever found yourself rewriting the same validation logic for the third time on a new project and thinking, "There has to be a better way," that is exactly why I built GladiosWAF.

I built it because I was tired of repeating the same security checks.

But more importantly, I built it because I realized repetition creates risk.

Every manual rewrite is another chance to miss something.

Every new stack is another place where the implementation can differ.

Every new endpoint is another opportunity for a gap.

GladiosWAF is my attempt to reduce that repeated work and provide a smarter, reusable layer in front of modern web applications.

It is not a silver bullet.

It is not a replacement for secure coding.

But it is a practical step toward making web security less repetitive, less fragile, and easier to apply across different projects.

Final Thoughts

Modern applications are not getting simpler.

APIs are everywhere. JSON payloads are common. GraphQL is more widely used. Applications rely on multiple services. Attack traffic is more automated, more varied, and easier to mutate.

At the same time, developers are still expected to manually repeat many of the same security checks across projects and stacks.

That is not ideal.

Security should not depend entirely on whether a tired developer remembered to rewrite the same defensive logic correctly at midnight.

There should be a smarter layer in front.

A layer that helps inspect suspicious traffic before it reaches the application.

A layer that reduces repeated security work.

A layer that lets developers focus more on business logic while still adding protection against malicious input.

That is the idea behind GladiosWAF.

And that is why I built it.

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