SQL injection: when a text field talks to your database

A SQL injection happens when text typed by a visitor is treated by the database as a command instead of plain data. The remedy has been known for a long time, and it is simple to apply.

The analogy: the letter to the clerk

Your application writes letters to the database, for example: "Find the customer whose name is...", then it copies in whatever the visitor typed in the field.

If the visitor types a name, all is well. But if what they type itself looks like an instruction, the clerk reads the whole letter and can no longer tell where the application's request ends and the visitor's text begins. They may then follow an order that nobody legitimate wrote.

Why it is serious

Depending on what the database allows, someone could read data they should not see, change it, or delete it. The attack targets the most valuable part of a product: its data.

Where does it happen?

Anywhere outside text is pasted into a query: a search box, a login form, a URL filter, an API parameter. Code written quickly, or generated without review, sometimes contains it.

The remedy: keep the request and the data apart

The solution comes down to one idea: never build a query by gluing text together.

• Use parameterized queries (also called "prepared"): the query is sent first with empty slots, then the values are passed separately. The database knows those values are data, whatever they contain.
• ORMs and modern query builders do this by default, as long as you do not bypass them by gluing text by hand.
• Give the application's database account the minimum rights: if a flaw slips through, the damage stays limited.
• Validate what you expect (a number, a date, a list of choices): this is a complement, never the main remedy.
• Do not show technical error messages to visitors.

A good sign to look for

In well-written code, a query and its values are never in the same sentence: the query says what to do, and the values travel separately. If you see queries assembled by hand from pieces of text, that is the spot to review first.

Key takeaway

Data must never become a command. Parameterized queries, minimal rights, and nobody gluing text into a query.

And for your product?

If your application was written quickly, by several hands or with an AI's help, you may not know how its queries are built. A code audit can check how queries are built and prioritize what needs it. We can talk about it in a 30-minute conversation.

Also worth reading: XSS, its browser-side cousin, database access rules and common flaws in AI-built apps.