Skip to Content
SécuritéPartie 6 — InjectionsVue d'ensemble

Partie 6 — Injections

⏱️ TL;DR — Une injection survient quand une entrée non fiable est interprétée comme du code (ou une commande) par un interpréteur : base SQL, shell système, moteur NoSQL, annuaire LDAP, moteur de templates. La reine est l’injection SQL (SQLi), qui peut lire, modifier ou détruire toute la base — et elle vient presque toujours du même geste fatal : concaténer une entrée dans une requête. La parade est universelle et simple : ne jamais mélanger code et données — on paramètre (requêtes préparées, ORM), le moteur traitant alors l’entrée comme une pure valeur, jamais comme du code. Cette partie couvre SQLi (PDO, Doctrine), command/NoSQL/LDAP injection, et la défense en profondeur.

Le problème qu’on résout

L’injection est l’une des plus anciennes et des plus dévastatrices familles de failles — elle figure au Top 10 OWASP depuis toujours. Son coût est énorme : une seule requête SQL vulnérable peut livrer l’intégralité d’une base de données (tous les comptes, tous les mots de passe hachés, toutes les données personnelles), permettre de contourner l’authentification, ou d’effacer des tables.

Et pourtant, sa cause racine est presque toujours la même erreur banale : construire une commande en collant une entrée utilisateur dedans, par concaténation de chaînes. Comprendre ce mécanisme unique, c’est comprendre toutes les injections d’un coup — et la parade (séparer code et données par le paramétrage) est tout aussi universelle.

Ce que tu sauras faire à la fin de cette partie

  • Expliquer le mécanisme commun à toutes les injections : entrée traitée comme code.
  • Reconnaître une injection SQL et la fermer par requêtes préparées (PDO) et ORM (Doctrine).
  • Traiter les cas où le paramétrage ne s’applique pas directement (identifiants, ORDER BY) via des allow-lists.
  • Reconnaître les autres injections : command injection, NoSQL, LDAP, et leurs parades.
  • Empiler les couches : paramétrer plus valider, moindre privilège de la base, échapper en dernier recours.

Les chapitres

#ChapitreEn un mot
6.1Le principe des injectionsCode vs données, le mécanisme commun, pourquoi la concaténation tue.
6.2SQLi & requêtes préparéesInjection SQL, PDO préparé, Doctrine, allow-list pour les identifiants.
6.3Command, NoSQL & LDAPInjection de commande shell, NoSQL, LDAP : mêmes causes, mêmes parades.
6.4Défense en profondeurParamétrer + valider + moindre privilège DB + gestion des erreurs.

Les injections traitent le cas où une entrée devient du code côté serveur. Le chapitre suivant traite le cas symétrique côté navigateur : la Partie 7 — XSS & sécurité côté client, où une entrée devient du JavaScript exécuté chez la victime.


On commence par le mécanisme, valable pour toutes : Le principe des injections.

Last updated on