Injection SQL : quand un champ de texte parle à votre base de données

Une injection SQL arrive quand un texte saisi par un visiteur est traité par la base de données comme une commande au lieu d'être traité comme une simple donnée. La parade existe, elle est connue depuis longtemps, et elle est simple à appliquer.

L'analogie : la lettre au guichetier

Votre application écrit des lettres à la base de données, par exemple : « Cherchez le client dont le nom est… », puis elle recopie ce que le visiteur a tapé dans le champ.

Si le visiteur tape un nom, tout va bien. Mais si ce qu'il tape ressemble lui-même à une instruction, le guichetier lit la lettre entière et ne sait plus où s'arrête la demande de l'application et où commence le texte du visiteur. Il peut alors obéir à une consigne que personne de légitime n'a écrite.

Pourquoi c'est grave

Selon ce que la base autorise, on peut lire des données qu'on ne devrait pas voir, les modifier, ou les supprimer. L'attaque vise le point le plus précieux d'un produit : ses données.

Où ça arrive ?

Partout où du texte venant de l'extérieur est recollé dans une requête : un champ de recherche, un formulaire de connexion, un filtre d'URL, un paramètre d'API. Du code écrit vite, ou généré sans relecture, en contient parfois.

La parade : séparer la demande et la donnée

La solution tient en une idée : ne jamais fabriquer la requête en collant du texte.

• Utilisez des requêtes paramétrées (ou « préparées ») : la requête est envoyée d'abord avec des emplacements vides, puis les valeurs sont transmises à part. La base sait que ces valeurs sont des données, quoi qu'elles contiennent.
• Les ORM et les constructeurs de requêtes modernes le font par défaut, à condition de ne pas les contourner en recollant du texte à la main.
• Donnez au compte de la base de l'application le minimum de droits : si un défaut survient, les dégâts restent limités.
• Validez ce que vous attendez (un nombre, une date, une liste de choix) : c'est un complément, jamais le remède principal.
• Ne montrez pas les messages d'erreur techniques aux visiteurs.

À retenir

Une donnée ne doit jamais devenir une commande. Requêtes paramétrées, droits minimaux, et personne ne recolle du texte dans une requête.

Et pour votre produit ?

Si votre application a été écrite vite, par plusieurs mains ou avec l'aide d'une IA, vous ne savez peut-être pas comment ses requêtes sont construites. Un audit de votre code permet de vérifier comment les requêtes sont construites et de prioriser ce qui doit l'être. On peut en parler pendant un échange de 30 minutes.

À lire aussi : le XSS, son cousin côté navigateur, les règles d'accès à la base et les failles fréquentes des applications générées par IA.