SQL injection

What it means

SQL injection is an attack in which the attacker slips their own database command into an application through a form, a search field or a page address. If the application does not validate the input, the database runs the command and the attacker can read, change or delete data they would otherwise have no access to.

It is among the oldest and still most widespread web application vulnerabilities, alongside cross-site scripting. The cause is almost always a coding error where the application builds a database query directly from text entered by the user, without separating data from the command.

The consequences can be serious: leaked customer databases, login credentials or payment information, altered prices in an online store or complete destruction of data. For a company this often also means a personal data breach with all the duties that follow from it.

How it works in practice

The most effective protection is proper coding with parameterised queries, where the database always treats user input as data and never as a command. This is complemented by input validation, minimal privileges for the database account and regular updates of the libraries and systems used.

Companies commissioning a website, online store or customer portal should include secure development requirements in the contract with the supplier and the right to have the application tested. Regular penetration tests uncover vulnerabilities before an attacker finds them.

Sensitive data in the database, such as passwords, should be stored so that a leak causes no direct harm. Passwords are stored as secure hashes and other sensitive fields can be protected by encryption, so even a stolen database has limited value to the attacker.

What to watch out for

If a company discovers a data leak, it must act quickly under its incident response plan. A personal data breach generally has to be reported to the supervisory authority within 72 hours and, where the risk is high, to the data subjects too, or further penalties may follow.

The controller remains responsible for application security even if an outside supplier built it. The contract should cover liability for defects and their repair, and the company may consider cyber insurance to cover part of the costs after an incident.