Imaginez que votre assistant IA préféré, celui qui génère du code ou résume des rapports, commence soudainement à afficher les numéros de sécurité sociale de vos clients directement dans le navigateur. Ce n'est pas une hypothèse farfelue. En 2024, Black Duck a révélé que 78 % des organisations utilisant des assistants de code IA ont subi au moins un incident de sécurité lié à une mauvaise gestion des entrées et sorties. Le problème ne vient pas toujours d'un pirate brillant, mais souvent d'une simple négligence dans la façon dont nous traitons les données qui entrent et sortent des modèles de langage (LLM). Si vous pensez que la sécurité web classique suffit pour protéger vos applications IA, détrompez-vous. Les failles sont différentes, plus subtiles, et potentiellement bien plus coûteuses.
Sanitisation est le processus de nettoyage et de validation des données d'entrée pour empêcher les injections malveillantes et les fuites de données sensibles avant qu'elles n'atteignent le modèle d'IA. Contrairement aux bases de données traditionnelles où l'on se soucie principalement des injections SQL, ici, la menace pèse sur le prompt lui-même. Une donnée non nettoyée peut transformer une requête anodine en une attaque par injection de prompt, permettant à un utilisateur mal intentionné de contourner les garde-fous éthiques ou techniques du modèle.
Pourquoi la sécurité traditionnelle échoue face à l'IA générative
Les frameworks classiques comme l'OWASP Top 10 ont été conçus pour des architectures web prévisibles. Mais les grands modèles de langage introduisent une couche d'imprévisibilité. L'OWASP Foundation, dans sa mise à jour de janvier 2025, a classé "LLM05: Improper Output Handling" (Gestion inappropriée des sorties) comme une vulnérabilité critique distincte. Pourquoi ? Parce que contrairement à une base de données qui retourne des structures rigides, un LLM génère du texte brut qui peut être interprété différemment selon le contexte d'affichage.
Prenez l'exemple d'une application médicale. Si le modèle génère un tableau HTML contenant des données patients sans encodage approprié, un script JavaScript malveillant inclus dans les données textuelles pourrait s'exécuter automatiquement dans le navigateur du médecin. C'est ce qu'on appelle une XSS (Cross-Site Scripting), mais déclenchée par l'IA elle-même. SentinelOne a constaté que les organisations appliquant des pratiques complètes de sanitisation rapportaient 63 % moins d'incidents de sécurité que celles se contentant de validations basiques. La différence est nette : il ne s'agit pas seulement de bloquer les caractères spéciaux, mais de comprendre l'intention derrière chaque token généré.
La sanitisation : filtrer avant que ça ne devienne toxique
La première ligne de défense consiste à nettoyer tout ce qui entre dans le système. Cela semble évident, mais c'est souvent là que les développeurs prennent des raccourcis. StackHawk recommande dans son guide de novembre 2024 d'utiliser systématiquement des requêtes paramétrées plutôt que de la concaténation de chaînes de caractères. C'est une règle d'or héritée du développement web traditionnel, mais elle prend une nouvelle importance avec l'IA.
Comment faire concrètement ? Vous devez mettre en place des règles de validation qui rejettent automatiquement les prompts contenant des motifs sensibles. Par exemple, si votre application traite des paiements, bloquez les séquences de 16 chiffres ressemblant à des cartes de crédit avant même qu'elles n'atteignent le LLM. Boxplot suggère également l'utilisation de classificateurs entraînés sur des motifs de données sensibles pour filtrer les entrées. Imaginez un filtre intelligent qui reconnaît un numéro de compte bancaire et le masque (par exemple, remplaçant "1234-5678" par "XXXX-XXXX") avant l'envoi au modèle. Cela réduit le risque que le LLM mémorise ou expose accidentellement ces informations dans ses réponses futures.
Mais attention au piège de la sur-sanitisation. Un cas documenté montre que des filtres trop stricts ont bloqué 18 % de terminologie médicale légitime car elle ressemblait à des motifs de données personnelles identifiables (PII). Trouver l'équilibre demande des listes blanches personnalisées pour votre domaine spécifique.
L'encodage contextuel : adapter la sortie à son environnement
Une fois que le LLM a produit une réponse, le travail n'est pas terminé. C'est ici que l'Encodage devenant crucial, il s'agit de transformer les caractères spéciaux de la sortie pour qu'ils soient affichés comme du texte littéral et non exécutés comme du code, selon le contexte de destination. L'erreur commune consiste à appliquer un encodage HTML universel partout. Or, si votre sortie est destinée à une base de données, vous avez besoin d'un échappement SQL. Si elle va dans un fichier JSON, l'encodage doit respecter les normes JSON.
Les directives de sécurité Gen AI d'OWASP insistent sur cet encodage conscient du contexte. Sysdig a démontré dans une étude comparative qu'une implémentation d'encodage contextuel réduisait les vulnérabilités XSS de 89 % par rapport à un encodage HTML basique. Concrètement, cela signifie vérifier où va la donnée. Va-t-elle dans un attribut HTML ? Dans une balise script ? Dans un champ de formulaire ? Chaque destination a ses propres règles d'échappement.
| Contexte de destination | Risque principal | Technique recommandée | Efficacité relative |
|---|---|---|---|
| Affichage Web (HTML) | XSS / Injection JS | Encodage HTML complet (<, >, &) | Élevée |
| Requête Base de Données | Injection SQL | Échappement SQL ou requêtes paramétrées | Très élevée |
| Interface Markdown | Exécution de scripts cachés | Sanitisation des balises HTML résiduelles | Moyenne à Élevée |
| Logs Système | Injection de commandes shell | Suppression des caractères de contrôle | Modérée |
Le principe du moindre privilège appliqué à l'IA
Vous connaissez probablement le concept de moindre privilège en informatique : ne donner à un utilisateur que les droits strictement nécessaires. Avec l'IA, cette notion prend une dimension encore plus critique. Snyk liste "Restreindre l'accès aux données pour votre LLM" comme l'une de ses trois meilleures pratiques. Pourquoi ? Parce que les modèles ont tendance à "sur-apprendre" ou à accéder à des bases de connaissances vastes si on ne les limite pas.
Dans le secteur de la santé, soumis à la norme HIPAA, cela est non négociable. StackHawk précise que toutes les données de santé protégées (PHI) doivent être chiffrées au repos et en transit avec AES-256 et TLS 1.2+. Plus important encore, le principe du "minimum necessary" s'applique : le LLM ne devrait voir que les champs de données indispensables à la tâche en cours. Black Duck note une réduction de 41 % des incidents d'exposition de données lorsque ce principe est appliqué rigoureusement.
Concrètement, cela implique une revue trimestrielle des accès, comme le mandate le NIST dans ses lignes directrices provisoires AI 100-2 publiées en janvier 2025. Non seulement les humains qui utilisent l'outil doivent avoir des droits limités, mais l'agent IA lui-même doit opérer dans un bac à sable restreint. Il ne doit pas avoir accès à l'ensemble de la base de clients si la question posée concerne uniquement les produits vendus au dernier trimestre.
Outils et implémentation : passer de la théorie à la pratique
Heureusement, vous n'avez pas tout à inventer. Des solutions émergent pour automatiser ces contrôles. Lakera, par exemple, a développé "Gandalf", une suite de gardiens d'entrée et de sortie. Leur approche multi-couches a réduit le taux de succès des injections de prompt de 47 % à seulement 2,3 % dans leurs environnements de test. D'autres acteurs comme Varonis proposent des solutions de protection des données qui détectent les motifs sensibles avec une précision de 92 %, selon les retours utilisateurs sur G2 Crowd.
Si vous débutez, voici une feuille de route réaliste :
- Semaine 1-2 : Implémentez la validation d'entrée stricte. Rejetez les prompts trop longs ou contenant des motifs PII évidents.
- Semaine 3-4 : Intégrez l'encodage de sortie contextuel. Commencez par sécuriser les affichages HTML, puis étendez aux exports CSV ou JSON.
- Mois 2 : Restreignez les permissions API du LLM. Assurez-vous qu'il ne peut interroger que les tables autorisées.
- Continu : Mettez en place une journalisation (logging) des prompts inhabituels. Boxplot recommande une rétention de 30 jours pour analyser les anomalies.
N'oubliez pas que la documentation joue un rôle clé. L'OWASP Gen AI Security obtient une note technique de 4,7/5, mais souffre d'un manque d'exemples concrets (note de 3,2/5). Complétez donc les ressources officielles par des tests internes réguliers.
Erreurs courantes et comment les éviter
La tentation est grande de penser qu'un seul niveau de sécurité suffit. Erreur. La défense en profondeur est essentielle. Voici les pièges les plus fréquents observés chez les développeurs :
- Faux positifs excessifs : Comme mentionné plus tôt, bloquer des termes techniques valides parce qu'ils ressemblent à des numéros de téléphone. Solution : créer des allowlists spécifiques au domaine métier.
- Négliger la sortie : Beaucoup valident l'entrée mais oublient que le LLM peut halluciner du code exécutable. Toujours encoder la sortie.
- Confiance aveugle dans les filtres intégrés : Les filtres de contenu des fournisseurs cloud (Azure, AWS) sont utiles mais ne remplacent pas une logique métier propre. Ajoutez vos propres vérifications.
En fin de compte, sécuriser l'IA revient à traiter chaque interaction comme une transaction financière sensible. Vous ne laissez pas un inconnu accéder à votre coffre-fort sans vérifier son identité et limiter ce qu'il peut toucher. Faites de même avec vos modèles de langage.
Qu'est-ce que la sanitisation dans le contexte de l'IA ?
La sanitisation est le processus de nettoyage des données d'entrée pour éliminer les caractères dangereux ou les motifs sensibles avant qu'ils ne soient traités par le modèle d'IA. Elle vise à prévenir les injections de prompt et les fuites de données personnelles.
Pourquoi l'encodage est-il différent pour l'IA par rapport au web classique ?
Parce que les LLM génèrent du texte libre qui peut être interprété comme du code dans divers contextes (HTML, SQL, Markdown). L'encodage doit donc être contextuel, adapté à la destination finale de la sortie, pour éviter l'exécution involontaire de scripts ou de commandes.
Comment appliquer le principe du moindre privilège à un LLM ?
Il faut limiter techniquement l'accès du modèle aux données. Cela passe par des restrictions d'API, l'utilisation de vues de base de données limitées, et le chiffrement des données sensibles. Le modèle ne doit pouvoir consulter que les informations strictement nécessaires à la requête en cours.
Quels sont les risques si je n'encode pas correctement la sortie ?
Vous risquez des attaques XSS (Cross-Site Scripting) si la sortie contient du HTML non échappé, des injections SQL si elle est utilisée dans des requêtes, ou des erreurs de parsing si elle est injectée dans des formats structurés comme JSON ou YAML.
Combien de temps prend l'implémentation de ces mesures de sécurité ?
Selon StackHawk, un cadre de sanitisation de base prend généralement 2 à 4 semaines. Pour les applications critiques nécessitant une conformité réglementaire (comme HIPAA), comptez 3 à 5 semaines supplémentaires pour les mesures spécifiques.
