What is SQL injection and how to avoid it when creating a website?

Published on 2026-10-20 by frfrand

SQL injection explicada para principiantes: qué ocurre al mezclar consultas y datos, por qué funcionan las consultas parametrizadas y cómo reducir riesgos.

An SQL injection is a vulnerability that appears when an application incorporates untrusted data into SQL statements in an insecure way. Under certain conditions, an attacker can make the database engine interpret part of that data as code and execute a query different from the intended one.

The essential idea is very simple: one thing is the data a person writes, and another is the instructions the program decides to execute. Confusing them is the problem.

The example of an order sheet

Imagine you run a store. Your system allows searching for a product by name. The correct approach would be to use the name as data within an already defined query.

But a poorly designed program could build the query by joining text fragments with whatever the user has written. Thus, someone can try to introduce characters or instructions that change the meaning of the search.

We do not need to build an attack to understand the error: it occurs because the program lets external content intervene in the structure of a statement.

What could happen?

Depending on the permissions of the account used by the application and how the queries are built, the flaw may allow obtaining information that does not correspond, modifying records, or affecting service availability.

That does not mean that every SQL injection grants full control of the server. The impact depends on multiple factors: possible queries, engine used, permissions, and architecture.

That is why limiting the privileges of the database user is a valuable additional protection, although it does not fix the root vulnerability.

How to avoid it? Parameterized queries

The most important defense consists of separating the SQL structure from external values. Parameterized queries use placeholders and pass the data separately, so that the engine treats them as values and not as fragments of SQL code.

In Python with a compatible driver, a conceptual example would be:

cursor.execute(
    "SELECT id, nombre FROM productos WHERE nombre = %s",
    (nombre_buscado,)
)

The marker used depends on the library. What matters is not copying that symbol literally in any language, but using the driver's official parameter mechanism.

It is not recommended to build the query by manually concatenating quotes around the data. Escaping characters by hand is often fragile and very easy to get wrong.

What about ORMs?

Frameworks like Django include an ORM that allows performing many queries without writing SQL manually. This usually reduces the risk when its operations and filters are used correctly.

But using an ORM does not make you immune. If you execute raw SQL queries, build unsafe dynamic expressions, or accept column and table names without control, you can still introduce problems.

For dynamic parts that do not support direct parameterization —such as some SQL identifiers— explicit allowlists and appropriate provider methods are needed.

Does form validation help?

Validation helps data meet business rules, but it does not replace parameterization.

Limiting a person to twenty characters does not prove the value is safe for any context. Protections must be applied where the query is built.

It is also advisable to check database user permissions: an application that only reads a set of tables should not receive unlimited administrative privileges.

What about an application firewall?

A WAF can block certain malicious patterns, but it does not fix vulnerable code. Some harmful requests may get through, and some legitimate ones may be blocked by mistake.

The robust solution starts within the application, with parameters, authorization, and testing.

How to test defensively?

Check the points that accept external information, use automated tests and appropriate analysis tools within an authorized environment. Verify the queries built by the code and ensure that values are never interpreted as instructions.

In production, avoid showing detailed SQL errors to the public because they can reveal internal information. Keep useful diagnostic logs in a protected system.

Where does ArduMaker come in?

If you host a Django, Node, or any other backend application with PostgreSQL on ArduMaker, queries are the responsibility of your application. The server can keep the database on a private network, but that does not replace parameterization or permission control.

In summary: SQL injection occurs when data crosses the boundary and becomes commands. Maintaining that separation is the primary defense.

Sources: SQL Injection Prevention in OWASP · PostgreSQL Guide · How a database is compromised.