Qu'est-ce que l'injection SQL et comment la prévenir ?

Question

Accepted Answer

**L'injection SQL** est une vulnérabilité où un attaquant insère du SQL malveillant par le biais d'une entrée utilisateur — manipulant les requêtes de base de données pour voler des données, contourner l'authentification ou endommager les données. C'est l'une des vulnérabilités web les plus dangereuses et les plus classiques, mais elle est préventible avec les bonnes techniques.

## Comment fonctionnne l'injection SQL

```text
When user input is concatenated directly into a SQL query, an attacker can INJECT SQL:
```

```js
// ❌ VULNERABLE — user input concatenated into the query
const query = `SELECT * FROM users WHERE email = '${userInput}'`;
// attacker enters:  ' OR '1'='1
// → SELECT * FROM users WHERE email = '' OR '1'='1'   → returns ALL users!
// or:  '; DROP TABLE users; --   → could delete the table
```

L'entrée de l'attaquant est traitée comme du **code SQL** plutôt que comme des données — lui permettant de réécrire la requête (contourner la connexion, dumper toutes les données, supprimer des tables).

## Prévention : requêtes paramétrées (le correctif principal)

```js
// ✅ PARAMETERIZED / PREPARED statements — input is treated as DATA, never as code
const query = 'SELECT * FROM users WHERE email = ?';
db.execute(query, [userInput]);     // the value is safely bound, not concatenated
// → the database treats userInput as a literal value → injection impossible
```

**Les requêtes paramétrées (prepared statements)** séparent le code SQL des données — l'entrée ne peut jamais être interprétée comme du SQL. C'est la défense principale et fiable.

## Défenses supplémentaires

```text
✓ PARAMETERIZED queries / prepared statements → the #1 fix (always use them)
✓ ORMs/query builders → use parameterization under the hood (but don't bypass with raw
  string concatenation)
✓ INPUT VALIDATION (defense in depth) — validate/sanitize, but NOT a substitute for
  parameterization
✓ LEAST PRIVILEGE DB accounts (limit damage); avoid exposing detailed DB errors
→ NEVER build queries by concatenating user input.
```

## Pourquoi c'est important

Comprendre l'injection SQL et comment la prévenir est essentiel car c'est **l'une des vulnérabilités web les plus dangereuses, les plus classiques et les plus courantes** (faisant partie de la catégorie injection OWASP), mais entièrement préventible, donc c'est une connaissance de sécurité incontournable pour tout développeur travaillant avec des bases de données.

Comprendre **comment elle fonctionne** — que la concaténation directe d'une entrée utilisateur dans des requêtes SQL permet à un attaquant **d'injecter du code SQL** (son entrée traitée comme du code plutôt que comme des données), lui permettant de contourner l'authentification (`' OR '1'='1`), dumper toutes les données, ou même supprimer des tables (`'; DROP TABLE`) — est nécessaire pour reconnaître et éviter la vulnérabilité.

L'injection SQL peut être catastrophique (violation de données complète, destruction de données, contournement d'authentification), ce qui la rend critiquement importante.

Comprendre la **prévention** est essentiel : **les requêtes paramétrées (prepared statements)** sont le correctif principal et fiable — elles **séparent le code SQL des données** afin que l'entrée utilisateur soit traitée comme une valeur littérale qui ne peut jamais être interprétée comme du SQL, rendant l'injection impossible.

C'est la défense n°1 que tout développeur doit utiliser.

Comprendre les **défenses supplémentaires** — utiliser les ORMs/query builders (qui paramétralisent, mais pas en les contournant avec une concaténation brute), la validation des entrées comme défense en profondeur (mais pas en substitut de la paramétrisation), les comptes de base de données avec privilèges minimaux, et éviter l'exposition détaillée des erreurs — et la règle cardinale de **ne jamais concaténer l'entrée utilisateur dans les requêtes** reflète une prévention complète.

Puisque l'injection SQL est une vulnérabilité dangereuse, courante et classique avec des conséquences graves (violation de données, perte de données, contournement d'authentification) qui est entièrement préventible avec des requêtes paramétrées, et puisque comprendre comment elle fonctionne et comment la prévenir est essentiel pour tout développeur travaillant avec des bases de données, comprendre l'injection SQL et sa prévention est une connaissance de sécurité essentielle et incontournable — une vulnérabilité fondamentale à comprendre et contre laquelle se défendre, où le correctif simple et fiable (requêtes paramétrées) est une connaissance critique qui prévient l'une des classes d'attaques les plus dommageables.