Why a WAF should check your SQL, not just your HTTP requests
Most web application firewalls work at one point: the front door. They read each HTTP request, compare it with rules, and decide whether it looks like an attack.
That works well, and it’s where most attacks are stopped. But it has a blind spot. The firewall judges what the request looks like, not what it does once it reaches your code.
The gap between the request and the query
SQL injection succeeds when input from a request changes the structure of a database query. The request is the delivery; the changed query is the damage.
A request rule has to guess, from the outside, whether a value will change a query. Attackers work on making that guess hard: splitting input across fields, encoding it, or using a part of the request the rules don’t expect. Good rules decode common disguises first, and DBshieldX does, but any rule that judges the request alone is still guessing.
The database sees the result directly.
Your app’s queries have shapes
A typical application sends a small number of distinct queries, over and over. Take the values out and they collapse into a short list of shapes:
select id, title from todos where owner_id = ? and title like ?That shape might run thousands of times a day with different values. Its structure never changes, because your code builds it the same way every time.
An injection changes the structure: an extra clause, a second statement, a call to a delay function, a read from the database’s system catalog. The values are different, and so is the shape.
Learn the shapes, flag the new ones
That’s the idea behind the database layer in DBshieldX:
- it learns each app’s query shapes from normal use, with the values removed;
- a query with a shape it has never seen stands out, even if the request that caused it looked harmless at the front door;
- new shapes that contain stacked queries, delays or system-catalog reads get extra weight, because normal application code rarely produces them;
- it works from live statements or from a recorded PostgreSQL session log;
- it never stores the values in your queries.
It’s a second line of defence, not a replacement for request rules. The request check stops most attacks before they reach your code; the query check catches what changed a query anyway.
What it won’t do
Being honest about scope matters here. A query check doesn’t fix the injection: the fix is still parameterised queries in your code. And a brand-new feature that adds new queries will produce new shapes too, so expect to review a few new shapes after each release; most will be your own code.
What it gives you is a view from where your data actually lives, and a way to notice when something reaches the database that your app never sent before.
Read how database protection works in DBshieldX, or book a demo.