SQL injection explained simply

What is it, exactly?

Your site constantly asks its database questions: “give me product #42”, “does this password match this user?”. Those questions are written in SQL.

The problem appears when the site builds the question by pasting the visitor’s text straight into it. A clever visitor doesn’t just answer — they slip in a piece of their own question. It’s like letting someone finish the sentence you were about to say to the safe.

A concrete example

Picture a product page: app.example.com/product?id=42. Behind the scenes the site asks “the product whose id is 42”. If the attacker replaces 42 with 42 OR 1=1, the question becomes “the product whose id is 42 OR true” — and the database may return ALL products.

Sneakier variants return nothing visible but make the database “wait” a few seconds depending on the answer. By measuring that delay, the attacker reads your database letter by letter, without ever displaying it.

Why it’s serious

An exploitable SQL injection often grants access to the whole database: accounts, passwords, emails, your customers’ orders. Sometimes it allows logging in as admin without a password, or even taking over the server.

It’s one of the oldest flaws, yet still in the OWASP Top 10 (A03:2021 – Injection), because a single forgotten field is enough to open everything.

How to protect yourself

The golden rule: never paste the visitor’s text into an SQL query. Use prepared (“parameterised”) statements: write the question with blanks, and pass the values separately. The value can then no longer change the structure of the question.

Concretely: in PHP/PDO, prepare("SELECT * FROM products WHERE id = ?") then execute([$id]). In Python, cur.execute("… WHERE id = %s", (id,)). Add strict typing (an id must be a number) and a least-privilege database account. In production, hide detailed SQL error messages.

How SauronSec detects it

SauronSec sends benign probes to every parameter, header, cookie and JSON field, then measures the reaction. A delay that grows proportionally to the payload (0→3s, 6→6s) betrays a real injection — mere network latency does not track the payload.

Above all, each candidate is replayed twice and compared to a baseline response. Whatever does not reproduce is dropped: that’s how you get zero false positives. You only receive real flaws, with proof and the fix.