Sécuriser le NL2SQL : empêcher l’injection SQL générée par un LLM

Un prompt système qui dit « génère uniquement des requêtes SELECT » est une préférence, pas une barrière. Le modèle la respecte la plupart du temps parce qu’il a été entraîné à suivre les instructions, pas parce qu’une contrainte technique l’empêche physiquement d’écrire autre chose. Deux classes de défaillance rendent cette confiance insuffisante en production.

La première vient de la question elle-même. Un utilisateur, mal intentionné ou simplement créatif dans sa formulation, peut orienter la question de façon à pousser le modèle vers un SQL qu’il n’aurait pas dû écrire : une jointure vers une table sensible, un filtre qui contourne la logique attendue, un appel de fonction système. Le modèle ne distingue pas une question légitime d’une question conçue pour le manipuler.

La seconde ne nécessite aucune malveillance. Un modèle peut halluciner un nom de table, oublier le LIMIT que le prompt demandait, ou générer un SELECT * sans aucune restriction sur une table volumineuse. Le résultat est le même dans les deux cas : un SQL potentiellement coûteux ou intrusif, qui a passé le filtre du prompt et s’apprête à s’exécuter contre une vraie base.

La première ligne de défense consiste à parser le SQL produit par le modèle avec un vrai analyseur syntaxique pour le dialecte cible, puis à valider la structure obtenue, pas le texte brut. Une recherche de mots interdits dans la chaîne de caractères (« DROP », « DELETE », « ; ») se contourne trivialement : casse différente, commentaire inséré au milieu d’un mot-clé, guillemets typés. Un arbre syntaxique décrit sans ambiguïté ce que la requête fait réellement.

Aurabase implémente cette étape avec la crate Rust sqlparser et son dialecte PostgreSqlDialect, dans services/aura-ai/src/nl2sql/mod.rs. Avant même le parsing, un premier filtre lexical rejette deux constructions difficiles à raisonner correctement une fois dans l’arbre : le dollar-quoting ($$...$$), qui peut cacher un contenu arbitraire dans une chaîne, et les commentaires multi-lignes (/* */), qui peuvent masquer la fin réelle d’une instruction.

let dialect = PostgreSqlDialect {};
let mut statements = Parser::parse_sql(&dialect, sql)
    .map_err(|e| AuraError::BadRequest(format!("Erreur de parsing SQL: {}", e)))?;
if statements.len() > 1 {
    return Err(AuraError::BadRequest("Multi-statements non autorisés".to_string()));
}

Ce rejet du multi-statement bloque à lui seul la forme la plus connue d’injection SQL par empilement : SELECT * FROM users; DROP TABLE users;--. Le parseur ne renvoie qu’une seule instruction exploitable, la seconde n’est simplement jamais atteinte, quelle que soit la façon dont elle est formulée dans la question d’origine.

Une fois l’arbre obtenu, la validation la plus large consiste à n’accepter qu’un seul type de nœud racine, une requête (Statement::Query), et à rejeter tout le reste : INSERT, UPDATE, DELETE, DROP, CREATE, ALTER. Ce n’est plus une consigne de prompt, c’est une condition sur le type de l’objet parsé, qu’aucune formulation habile de la question ne peut contourner.

À l’intérieur même d’un SELECT, plusieurs constructions restent dangereuses et méritent leur propre rejet explicite :

Un cas de test tiré du dépôt illustre concrètement le dernier point : SELECT * INTO backup FROM users est rejeté, alors qu’il ne contient ni mot-clé d’écriture visible ni fonction suspecte. La forme de la requête suffit à la disqualifier.

Une liste noire de fonctions interdites (pg_sleep, pg_read_file, dblink...) oblige à anticiper chaque fonction dangereuse une par une, alors que Postgres en expose plusieurs centaines. Une liste blanche inverse la charge de la preuve : seules dix fonctions sont autorisées, count, sum, avg, min, max, lower, upper, coalesce, date_trunc, now. Tout le reste est refusé par défaut, y compris une fonction légitime que personne n’a encore pensé à ajouter.

Une seule passe de validation ne suffit pas toujours. Un parcours structurel de l’arbre énumère ses points d’entrée un par un (projection, WHERE, JOIN, GROUP BY...), et il est facile d’en oublier un : une fonction interdite peut se cacher dans une clause FILTER (WHERE pg_sleep(10) IS NOT NULL), dans un ORDER BY intra-agrégat (sum(id ORDER BY pg_sleep(10))), dans WITHIN GROUP, DISTINCT ON, ou OFFSET.

#[test]
fn test_rejette_fonction_interdite_dans_filter() {
    assert!(validate(
        "SELECT count(*) FILTER (WHERE pg_sleep(10) IS NOT NULL) FROM users",
        None, None
    ).is_err());
}

Le validateur d’Aurabase ajoute donc une seconde passe exhaustive, qui traverse toutes les expressions de l’arbre où qu’elles se trouvent, indépendamment du parcours structurel. C’est une défense en profondeur assumée : si la première passe rate un cas, la seconde le rattrape.

SELECT * reste autorisé, il est utile pour l’exploration de données. Le risque n’est pas l’étoile, c’est l’absence de plafond sur une requête écrite par un modèle : une question mal formulée peut ramener une table entière, avec le coût mémoire et le temps de réponse que ça implique.

Aurabase applique une règle simple et transparente. Si le SQL généré ne porte pas de LIMIT, le serveur en ajoute un (100 lignes par défaut, valeur annoncée au modèle dans le prompt système). Si le SQL demande un LIMIT au-delà d’un plafond dur (1000 lignes par défaut), la requête est refusée explicitement plutôt que silencieusement réduite. Les deux valeurs sont configurables côté serveur (AI_NL2SQL_DEFAULT_LIMIT, AI_NL2SQL_MAX_LIMIT), et le serveur refuse même de démarrer si le défaut dépasse le plafond.

{
  "sql": "SELECT count(*) FROM orders WHERE status = 'paid' LIMIT 100",
  "limit": 100,
  "limit_injected": true
}

Deux fuites distinctes menacent un moteur NL2SQL branché sur une base réelle : l’accès au catalogue système de Postgres, et l’accès à un schéma qui n’appartient pas à l’appelant. Les deux se bloquent à la validation, indépendamment de toute policy RLS posée en aval.

pg_catalog fait toujours partie du search_path, ce qui veut dire qu’un nom non qualifié comme pg_authid ou pg_stat_activity y accède directement, sans préfixe. Le validateur d’Aurabase bloque tout nom commençant par pg_, ainsi que information_schema et le schéma interne aura_console, qu’ils soient qualifiés ou non.

Sur un nom à deux composants (schema.table), seul le schéma du projet appelant est autorisé, toute autre valeur est rejetée. Un nom à trois composants ou plus est refusé d’office. Cette frontière au niveau de la requête générée s’ajoute à l’isolation au niveau base détaillée dans notre article sur l’isolation multi-tenant : l’une empêche le SQL généré de viser un autre schéma, l’autre empêche la connexion elle-même d’atteindre une autre base. Aucune des deux ne remplace l’autre.

Un piège discret guette toute API NL2SQL qui accepte un paramètre décrivant le schéma ou les tables autorisées dans la requête du client. Si ce même paramètre sert à construire le prompt et à valider le SQL en sortie, un appelant peut mentir sur ce qui est autorisé, et la validation valide alors contre ce mensonge plutôt que contre la réalité de la base.

Aurabase introspecte le schéma réel de la base du projet à chaque appel, avec un court cache de trente secondes pour la performance, et rejette explicitement (erreur 400) tout champ schema, allowed_schema ou schema_context envoyé dans le corps de la requête, plutôt que de l’accepter puis de l’écraser en silence. La différence compte : un champ accepté puis ignoré donne l’illusion d’un contrôle qui n’existe pas ; un champ refusé le dit tout de suite.

Que vous utilisiez Aurabase ou que vous construisiez votre propre pipeline au-dessus d’un LLM générique, les points suivants couvrent ce qui manque le plus souvent.

Si vous écrivez le validateur vous-même

• Parsez le SQL avec un vrai analyseur syntaxique pour votre dialecte exact, jamais avec une recherche de motifs dans une chaîne.
• Adoptez un rejet par défaut : tout type de nœud, toute fonction non explicitement autorisée doit être refusé, pas seulement les cas dangereux déjà identifiés.
• N’acceptez qu’un seul statement par requête, c’est le rejet le plus simple contre l’empilement de requêtes.
• Testez le validateur avec des cas adversariaux réels (fonction interdite dans FILTER, dans un ORDER BY intra-agrégat, dans OFFSET), pas seulement avec des cas évidents.
• Exécutez malgré tout le SQL validé avec un rôle Postgres à privilèges réduits sur le schéma attendu : le validateur borne la forme de la requête, le rôle borne ce qu’elle peut physiquement atteindre si un cas vous a échappé.

Si vous évaluez un framework NL2SQL tiers

• Demandez explicitement si la validation est structurelle (AST) ou seulement une consigne de prompt : la réponse change tout.
• Vérifiez qu’un plafond de lignes est appliqué par défaut, pas seulement documenté comme bonne pratique à votre charge.
• Vérifiez si le schéma utilisé pour la validation peut être fourni par le client de l’API, ce qui rouvrirait exactement la faille décrite plus haut.
• Comparez plusieurs outils sur ce critère précis avant de choisir : notre comparatif des outils NL2SQL détaille ce qui distingue les approches disponibles en 2026.

Un validateur AST solide réduit le risque à la source : le SQL qui atteint votre base a déjà une forme connue et bornée. Il ne remplace pas pour autant les policies RLS sur vos tables sensibles, qui décident quelles lignes un utilisateur donné a le droit de voir. Les deux couches répondent à des questions différentes : le validateur borne la forme de la requête générée, la RLS borne les données qu’elle peut retourner pour un utilisateur précis. Gardez les deux actives, même si l’une vous semble redondante avec l’autre.

Le NL2SQL couvre les questions structurées sur vos tables. Pour des questions sur du contenu non structuré, documents, notes, tickets, le RAG natif d’Aurabase suit une logique de sécurisation comparable, détaillée dans notre tutoriel pipeline RAG sur pgvector.