FlawOpen

flawopen.com/Injection SQL en Python/SQLAlchemy

SQLAlchemy text() protège-t-il contre les injections SQL ?

Guide de référence
Réponse courte

Un paramètre lié ressemble à une fiche scellée dans un formulaire de requête : SQLAlchemy transmet l’instruction SQL et son dictionnaire de paramètres au DBAPI sous-jacent, en gardant les valeurs hors de l’expression SQL construite par votre code. Le pilote DBAPI effectue la liaison propre à la base, le transport peut donc varier. text() accepte du texte SQL, mais ne nettoie ni ne paramètre les valeurs déjà interpolées dans ce texte.

NON SÛR — interpoler l’entrée dans SQL
stmt = text(
  f"SELECT id FROM users WHERE id = {user_id}"
)
rows = conn.execute(stmt)
RENFORCÉ — lier les valeurs et borner la structure SQL
stmt = text(
  "SELECT id FROM users WHERE id = :id"
)
rows = conn.execute(stmt, {"id": user_id})

# Bind values, not identifiers. Choose any
# selectable column from a fixed application map.
columns = {"name": users.c.name,
           "created": users.c.created_at}
column = columns.get(requested_sort, users.c.created_at)
stmt = select(users.c.id).order_by(column)
rows = conn.execute(stmt)

Ce que fait text() — et ses limites

text() crée une construction SQL textuelle ; il ne nettoie pas une chaîne qui contient déjà une entrée interpolée. Déclarez les placeholders dans le SQL et transmettez les valeurs séparément à Connection.execute() ou Session.execute(). L’API d’expressions Core lie les valeurs Python littérales lorsque c’est approprié, mais les fragments textuels restent de la syntaxe SQL. Les paramètres ne remplacent pas les noms de tables, de colonnes ni les directions de tri. Associez toute structure choisie par l’utilisateur à des expressions SQLAlchemy fixes. Le paramétrage prévient les injections SQL, mais ne remplace ni l’autorisation ni la validation métier.

Auditer votre code

rg -n 'text\(|\.execute\(' --glob '*.py' .

FAQ

Les constructeurs de requêtes Core et ORM SQLAlchemy sont-ils toujours sûrs ?

Ils lient les valeurs Python dans les constructions d’expressions habituelles, mais la sécurité dépend de la construction de la requête. Vérifiez le SQL textuel, les constructions SQL littérales et les identifiants dynamiques. Aucune API ne sécurise une chaîne SQL après concaténation de l’entrée.

Références

À voir aussi Injection SQL (CWE-89) : fonctionnement et prévention dans chaque langage — flawopen.com La vérification des requêtes sqlx à la compilation empêche-t-elle les injections SQL ? Les procédures stockées empêchent-elles l’injection SQL ? TypeORM QueryBuilder protège-t-il des injections SQL ? Django ORM et SQL Injection : bonnes pratiques Injection SQL dans Doctrine ORM : requêtes sûres EF Core FromSqlRaw : SQL paramétré sûr