INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q092 — Une requête préparée protège-t-elle contre toute forme d’injection dans tous les contextes, y compris les identifiants SQL dynamiques ?
Votre question porte sur les limites réelles des requêtes préparées face aux injections SQL. Je vais vous répondre avec précision.
**Réponse**
Non. Une requête préparée ne protège pas contre toute forme d'injection dans tous les contextes. Elle protège efficacement contre l'injection dans les valeurs (les paramètres), mais elle ne protège pas, en elle-même, contre l'injection dans les identifiants dynamiques (noms de tables, de colonnes, clauses ORDER BY, etc.).
**Justification**
Une requête préparée fonctionne en séparant la structure SQL (le squelette) des valeurs. Le serveur compile le squelette une fois, puis les paramètres sont transmis séparément, comme des données et non comme du code. C'est pourquoi une valeur paramétrée ne peut pas modifier la structure de la requête : c'est un mécanisme robuste contre l'injection dans les valeurs.
Cependant, ce mécanisme a une limite structurelle : il ne peut paramétrer que des valeurs scalaires (chaînes, nombres, dates). Les identifiants SQL — noms de tables, de colonnes, de schémas, ou encore les clauses dynamiques comme ORDER BY, LIMIT, ou les fragments de requête — ne sont pas des valeurs : ce sont des éléments de structure. La plupart des moteurs SQL refusent de les accepter comme paramètres liés. Par conséquent, si un développeur concatène un identifiant dans le squelette de la requête, la protection de la requête préparée ne s'applique plus du tout à cette partie.
**Contre-exemple concret**
Considérons une application qui trie des résultats selon une colonne choisie par l'utilisateur :
```
SELECT nom, prix FROM produits ORDER BY {colonne}
```
Si le code construit la requête ainsi :
```
"SELECT nom, prix FROM produits ORDER BY " + colonneUtilisateur
```
alors même si le reste de la requête est préparé, la variable `colonneUtilisateur` est insérée dans la structure. Un attaquant pourrait fournir :
```
prix; DROP TABLE produits; --
```
La requête préparée ne peut rien y faire, car l'identifiant n'est pas passé comme paramètre lié. La seule défense correcte est une liste blanche (whitelist) : vérifier que l'identifiant correspond exactement à une valeur autorisée, jamais le concaténer directement.
**Autres limites à signaler**
D'abord, les requêtes préparées ne protègent pas contre les injections dans les procédures stockées qui construisent elles-mêmes du SQL dynamique en interne. Ensuite, elles ne couvrent pas les contextes où le SQL est généré par des ORM de façon non paramétrée, ni les injections de second ordre (une valeur stockée en base puis réutilisée dans une autre requête non préparée). Enfin, une requête préparée ne protège pas contre les autres classes de vulnérabilités (XSS, CSRF, etc.).
**Confiance : 96 %**
Cette confiance est élevée car le raisonnement repose sur le fonctionnement standard et documenté des requêtes préparées dans les principaux moteurs SQL (PostgreSQL, MySQL, SQL Server, Oracle). Je laisse une petite marge car les comportements exacts de paramétrage des identifiants peuvent varier légèrement selon les moteurs et leurs versions, mais le principe général — les identifiants ne sont pas paramétrables — est stable et bien établi.
En résumé, la requête préparée est un rempart excellent pour les valeurs, mais elle n'est ni universelle ni suffisante seule : toute partie structurelle de la requête doit être traitée par validation stricte, idéalement une liste blanche.Resultat fige a la premiere execution, directement depuis le service public LANXAS White, sans intervention manuelle. Cette page est permanente et peut etre re-consultee pour verification.