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.