# SQL injection

> Typing text into a form that the database mistakes for its own instructions.

- Level: Intermediate
- Topics: Security, Data
- URL: https://tidbit.legios.com.ar/sql-injection/
- In Spanish: [Inyección SQL](https://tidbit.legios.com.ar/es/sql-injection/)

Behind most login forms and search boxes there is a database that speaks SQL. When you search a shop for 'red shoes', the website builds a command along the lines of `find products whose name contains: red shoes` and sends it to the database. **SQL injection** happens when the site builds that command by simply gluing your text into it. Then a visitor can type something that is not a search term at all but a fragment of SQL, and the database cannot tell where the site's instructions end and the visitor's begin.

Depending on what the attacker types, the changed command might return every customer's record instead of a few products, skip the password check on a login page, or alter data. It is one of the oldest web vulnerabilities, it has been behind many large data breaches, and OWASP still lists injection among the most important risks for web applications.

The fix is well known and not complicated: never build a command by pasting text together. Developers use **parameterized queries** (also called prepared statements), where the command is written first with a fixed placeholder and the user's input is passed separately, always treated as a value and never as code. Modern frameworks and libraries do this by default. On top of that, the database account the website uses should only be allowed to do what the site needs, so a mistake cannot become a disaster.

As a user you cannot do much about it, beyond using unique passwords so a leak from one site does not open your other accounts. As someone who hires or manages a team building software, it is worth asking whether queries are parameterized and whether the code has had a security review or a penetration test.

## An analogy

A bank teller who reads aloud whatever is written on the slip: 'Pay to: Ana Pérez'. If someone writes 'Ana Pérez, and also empty the vault', a careless teller reads it as one instruction. The fix is a form with a box for the name that is only ever treated as a name.

## Keep in mind

- It happens when user input is pasted straight into a database command.
- The database then runs part of the input as instructions.
- Parameterized queries keep input as data and prevent it.
- Limit the database permissions of the app to contain any mistake.

## Go deeper

- [SQL Injection (OWASP)](https://owasp.org/www-community/attacks/SQL_Injection)
- [SQL Injection Prevention Cheat Sheet (OWASP)](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)
- [SQL injection on Wikipedia](https://en.wikipedia.org/wiki/SQL_injection)

## Related terms

- [Database](https://tidbit.legios.com.ar/database/): An organized store of data that programs can search and update safely.
- [SQL](https://tidbit.legios.com.ar/sql/): The language you use to ask a database questions.
- [Vulnerability and CVE](https://tidbit.legios.com.ar/vulnerability-and-cve/): A flaw that lets an attacker misuse software, and the public id that names it.
- [Data breach](https://tidbit.legios.com.ar/data-breach/): When private data an organization holds ends up with people who should not have it.
- [Framework](https://tidbit.legios.com.ar/framework/): A ready-made skeleton for an app: it sets the structure and calls your code.
- [Penetration testing](https://tidbit.legios.com.ar/penetration-testing/): Hiring someone to break into your systems, with permission, before a criminal does.