IA dans vos applis web : 7 attaques qui finissent en fuite de données (parades dev à Lyon)

Le problème n’est pas “l’IA”. C’est ton appli web (et tes accès)

À Lyon comme ailleurs, les fuites de données d’applications web suivent rarement le scénario “0-day hollywoodien”. Le retour terrain est plus banal, et donc plus dangereux : des accès trop larges, des sessions qui traînent, des secrets qui fuitent, des dépendances pas patchées, une config cloud exposée… et vos données partent.

Le CERT-FR indique avoir suivi 196 exfiltrations en 2025, contre 130 en 2024, soit une hausse de plus de 50 %. Et il souligne un point qui pique : dans de nombreux cas, l’attaque est de faible complexité, sans exploitation de vulnérabilité technique. Autrement dit : l’attaquant se connecte “normalement”, puis abuse de ce que vous avez déjà laissé possible. Source : CERT-FR (ANSSI), RETEX publié le 20 octobre 2026.

Ajoutez la couche IA. Vous branchez un assistant GenAI, un plugin, un connecteur CRM, un outil d’agent… et vous ouvrez un nouveau robinet à données. Pas besoin d’un malware pour perdre un fichier client.

Objectif ici : comprendre 7 modes de compromission fréquents qui mènent à une fuite de données application web, et les bloquer côté dev/ops. Sans recettes offensives. Du concret. Et une checklist priorisée à la fin, pensée cybersécurité Lyon PME.

Les chiffres à garder en tête (pour arrêter de minimiser)

• 196 exfiltrations en 2025 suivies par le CERT-FR, contre 130 en 2024. Source : CERT-FR (ANSSI), CERTFR-2026-CTI-008.
• Le CERT-FR note que, dans beaucoup de cas, ça passe par des actions simples (identités, accès, contrôles insuffisants), pas par une “faille” au sens strict. Même source.
• Baromètre 2025 : 16 % des TPE-PME interrogées déclarent au moins un incident sur 12 mois, et parmi celles touchées 22 % évoquent un vol de données. Source : Cybermalveillance.gouv.fr.
• En 2024, plus de 5 600 violations de données personnelles ont été signalées à la CNIL. Source : Ma Sécurité (Ministère de l’Intérieur).

Les 7 attaques qui mènent aux fuites (et comment les bloquer côté dev)

1) Identifiants compromis : l’attaque “sans faille” qui suffit

Scénario classique : phishing, mots de passe réutilisés, credential stuffing. L’attaquant obtient un compte valide. Ensuite, il exporte. Il parcourt. Il télécharge. Et votre application l’aide, parce qu’elle fait exactement ce qu’elle a été conçue pour faire… pour un utilisateur légitime.

Pourquoi ça finit en fuite : parce que vos contrôles supposent que “connecté = autorisé” et que l’exfiltration ressemble à un usage normal (exports CSV, API de recherche, pages “mes documents”). C’est exactement le type de cas “faible complexité” mis en avant dans le RETEX du CERT-FR.

Parades dev/ops :

• MFA partout, en priorité sur admins, back-office, comptes support et accès VPN/SSO.
• Rate limiting et détection d’anomalies sur login, reset de mot de passe, et surtout sur les routes d’export et de download.
• Politiques de mot de passe réalistes, mais avec contrôle de mots de passe compromis (si possible via listes de hash, pas en clair).
• Journaux d’audit exploitables : qui a exporté quoi, quand, depuis quelle IP, avec quel user-agent, quel volume.

2) Sessions et jetons mal protégés : vous avez authentifié, puis vous avez lâché le volant

Beaucoup d’équipes verrouillent l’auth, puis oublient la session. Cookies volés (poste infecté, proxy, mauvais flags), sessions trop longues, refresh tokens non rotatifs, absence d’invalidation après changement de mot de passe, sessions réutilisées sur plusieurs appareils sans contrôle.

Pourquoi ça finit en fuite : la prise de session donne accès à tous les écrans et API déjà autorisés. Et comme c’est “déjà connecté”, vos systèmes de sécurité lèvent moins d’alertes.

Parades dev/ops :

• Cookies avec flags stricts : HttpOnly, Secure, SameSite adapté (souvent Lax par défaut, et évaluer Strict sur certaines apps).
• Durées courtes sur sessions sensibles, et rotation des tokens.
• Invalidation réelle : logout global, changement de mot de passe, désactivation compte, révocation refresh tokens.
• Détection : impossible travel, changements brutaux d’IP/ASN, pics de downloads, appels API en rafale.

3) Contrôles d’accès applicatifs insuffisants : l’IDOR et le multi-tenant qui saigne

Vous avez un RBAC “global”, mais vous oubliez la règle la plus simple : chaque objet doit être autorisé côté serveur. Pas côté front. Pas “parce que l’utilisateur ne voit pas le bouton”. Dans les APIs, c’est la base des fuites inter-clients.

Pourquoi ça finit en fuite : l’application renvoie des ressources d’un autre utilisateur ou d’un autre tenant, faute de vérification systématique. Souvent, ça passe dans les tests car tout marche “en parcours nominal”.

Parades dev/ops :

• Autorisation à la ressource (object-level) sur chaque endpoint : read, write, export, delete.
• Multi-tenant durci : scoping systématique tenant_id dans la couche data, pas juste dans la route.
• Tests : jeux de tests d’autorisation (A ne doit jamais lire B), intégrés en CI.
• Logs : tracer les refus d’accès (403) et les patterns de balayage (montée en volume d’erreurs).

4) Secrets exposés : Git, CI/CD, logs… et la clé ouvre tout

Une clé API de LLM, un token cloud, un mot de passe DB, un secret JWT… Ce n’est pas “juste” un secret. C’est souvent un pont direct vers vos données. Dans les PME, ça arrive vite : dépôts partagés, scripts de déploiement copiés-collés, variables d’environnement dupliquées entre dev et prod.

Pourquoi ça finit en fuite : une fois le secret récupéré, l’attaquant n’a plus besoin d’attaquer l’appli. Il peut interroger un stockage, une base, un SaaS, une API d’export. Et ça ne ressemble plus à une intrusion, juste à de l’API call.

Parades dev/ops :

• Gestion de secrets (vault, KMS, secrets manager) et interdiction des secrets en dur.
• Scan de secrets dans repos et CI (pré-commit et pipeline), plus rotation automatique quand fuite détectée.
• Scopes minimaux sur tokens : lecture seule si possible, accès restreints par IP, par ressource, par environnement.
• Hygiène de logs : ne jamais logger tokens, headers d’auth, prompts contenant données clients.

5) Injections et entrées non maîtrisées : vous validez au front, l’attaquant s’en fiche

SQL/NoSQL injection, template injection, injections via champs de recherche, upload de fichiers qui déclenche un traitement dangereux. Ce ne sont pas des reliques. Elles reviennent dès que vous ajoutez vite un endpoint “admin”, une feature “import CSV”, un rendu server-side, ou un parseur de fichiers.

Pourquoi ça finit en fuite : l’injection sert souvent à lire avant de détruire. Dump partiel, extraction par filtres, contournement de contrôles via requêtes manipulées. Même sans RCE, la fuite est possible.

Parades dev/ops :

• Requêtes paramétrées partout. Pas d’assemblage de requêtes “à la main”.
• Validation côté serveur : schémas stricts, taille max, formats, listes de valeurs autorisées.
• Upload durci : types MIME vérifiés côté serveur, stockage hors webroot, renommage, analyse antivirus si pertinent, sandbox si traitement.
• WAF en complément, pas comme excuse pour laisser passer du code fragile.

6) Dépendances et supply chain : le trou vient d’un package, pas de votre code

Librairies back, composants front, images Docker, plugins… Une dépendance vulnérable peut ouvrir un XSS persistant, une exécution de code, ou une exfiltration discrète. Le problème n’est pas “avoir des dépendances”. Le problème, c’est ne pas savoir lesquelles vous avez, ni quand patcher.

Pourquoi ça finit en fuite : exploitation à grande échelle de vulnérabilités connues, retard de patching, et chaînes CI qui buildent des images obsolètes. Le CERT (ANSSI) documente régulièrement ces dynamiques d’exploitation de masse et de rattrapage difficile.

Parades dev/ops :

• SBOM et inventaire : savoir ce qui tourne en prod, versions incluses.
• Scans SCA (dépendances) et scans d’images container dans la CI, avec seuils bloquants.
• Politique de mise à jour : fenêtres de patch régulières, process d’urgence sur CVE critiques.
• Verrouillage : dépendances pinées, registries maîtrisés, signatures quand possible.

7) Erreurs de configuration : la fuite par exposition, pas par piratage

Bucket public, base exposée, endpoint d’admin accessible, reverse-proxy trop permissif, CORS large, IAM “admin” par défaut, environnements dev ouverts… Là, il n’y a même pas “attaque”. Il y a accès. Et quelqu’un finit par le trouver.

Pourquoi ça finit en fuite : parce que l’exposition donne une lecture directe, ou parce qu’un rôle trop large permet de lister et aspirer. Et si vous branchez l’IA là-dessus, vous accélérez la fuite (un agent peut parcourir plus vite que vous).

Parades dev/ops :

• Infrastructure as Code + revue : pas de changements “clic-clic” non tracés.
• Segmentation réseau : admin derrière VPN, bastion, ou au minimum IP allowlist.
• IAM minimal : rôles par service, séparation prod/préprod, pas de clés partagées.
• Contrôles d’exposition continus : scans de surfaces, inventaire des endpoints, alertes sur ressources publiques.

Volet IA : assistants, plugins, agents… là où les fuites arrivent vraiment

“On a branché un assistant IA à notre SI” est devenu une phrase normale dans les boîtes lyonnaises. Sauf que vous venez d’ajouter :

• un nouvel utilisateur (l’agent),
• des nouveaux chemins de données (prompts, pièces jointes, contexte long),
• des nouveaux droits (scopes OAuth, tokens),
• des nouveaux journaux (traces, tickets support, APM).

Fuite n°1 : sur-partage de contexte (prompt et pièces jointes)

Le cas le plus fréquent n’est pas un hack. C’est un copier-coller. Ou un connecteur qui lit trop large. Vous mettez des données client dans le prompt pour “aller plus vite”. Ou vous autorisez l’assistant à indexer un drive entier.

Parades :

• Minimisation : pas de données perso si pas nécessaire, masquage/anonymisation quand possible.
• Scopes : accès au strict nécessaire, par dossier, par projet, par type de document.
• Garde-fous : listes de données interdites, validation humaine sur exports et actions sensibles.

Pour une grille rapide avant d’ouvrir des données à un assistant : https://lyon-ia.com/blog/fuite-de-donnees-7-controles-rapides-avant-douvrir-vos-donnees-a-un-assistant-ia.

Fuite n°2 : plugins et connecteurs trop permissifs

Un plugin avec des scopes trop larges peut lire plus que prévu. Pire, il peut agir (créer un export, ouvrir un ticket avec des données, envoyer un mail, pousser un fichier). Avec un agent, vous automatisez l’erreur.

Parades :

• Revue des scopes OAuth et droits API, comme une revue IAM classique.
• Principe du “read first” : commencer lecture seule, puis ouvrir l’écriture par étapes.
• Barrières : approbation explicite pour actions à impact (export, suppression, envoi externe).

Fuite n°3 : prompts et réponses finissent dans les logs

Vous ajoutez de l’observabilité. Très bien. Sauf que vous logguez des prompts contenant des données sensibles. Puis ça part dans un outil de log partagé, dans un ticket de support, dans un APM accessible à trop de monde.

Parades :

• Redaction : masquage automatique (PII, tokens, secrets) avant logs.
• Rétention courte sur traces contenant du texte libre.
• Contrôle d’accès strict sur outils de logs et de support.

Fuite n°4 : assistants de code et secrets qui partent dans la conversation

Un dev colle un bout de config. Ou un log. Ou une stacktrace avec token. Et l’assistant “aide”. Sauf que vous venez de déplacer un secret hors de votre périmètre de contrôle. L’ANSSI a publié un cadrage sur l’usage sécurisé des AI coding assistants.

Parades :

• Charte d’usage claire : jamais de secrets, jamais de données client, jamais de code propriétaire sensible sans validation.
• Outils : redaction côté poste, détection de secrets, politiques DLP si disponibles.
• Comptes : séparer comptes perso et comptes entreprise, SSO, journaux, révocation.

Ressource ANSSI : https://cyber.gouv.fr/nous-connaitre/publications/publications-internationales/ai-coding-assistants/?utm_source=openai.

Fuite n°5 : l’agent IA est un SI à lui tout seul

Un agent, ce n’est pas “juste un modèle”. C’est une app avec des identités, des permissions, des connecteurs, une mémoire (RAG), des logs, des workflows. Il faut le traiter comme tel.

Deux liens utiles côté Lyon IA si vous bossez déjà sur des agents et de l’automatisation :

• https://lyon-ia.com/blog/securiser-un-agent-ia
• https://lyon-ia.com/blog/agents-ia-10-garde-fous-avant-dautomatiser-en-entreprise-acces-donnees-actions

Checklist priorisée dev/ops (PME lyonnaise, équipe courte, impact max)

P0 : cette semaine (réduit le risque de fuite tout de suite)

• MFA sur admins, back-office, consoles cloud, outils CI/CD, SSO.
• Revue des exports : quelles routes/export CSV/PDF existent, qui y a accès, quels volumes, quelles limites.
• Logs d’audit sur actions à fuite : login, reset MDP, export, download massif, création de token, changements de rôles.
• Secrets : scan repos + rotation des clés à risque, suppression des secrets des logs.
• Quick win config : fermer endpoints admin exposés, vérifier stockages publics, vérifier CORS et en-têtes sécurité.

P1 : ce mois-ci (structure la défense, évite la récidive)

• Autorisation “object-level” standardisée sur vos APIs (IDOR, multi-tenant).
• Durcissement sessions : rotation tokens, invalidation globale, cookies durcis.
• SCA : scans dépendances et images, politique de patch avec SLA.
• Tests sécurité intégrés CI : tests d’autorisations, validations serveur, checks de config IaC.
• Segmentation : séparer prod/préprod, réduire les accès directs aux bases et stockages.

P2 : ce trimestre (niveau “on arrête de bricoler”)

• Threat modeling sur les parcours de données (exports, imports, recherche, endpoints admin).
• DLP pragmatique : au moins sur messagerie, drive, logs, et outils IA connectés.
• Playbooks fuite de données : détection, collecte de preuves, rotation secrets, communication, RGPD.
• Revue des intégrations IA : scopes minimaux, “read-only” par défaut, approbations pour actions.

Ce que vous pouvez faire demain matin (sans budget “grosse DSI”)

Si vous devez choisir trois actions, prenez celles qui cassent le plus de scénarios “faible complexité” décrits par le CERT-FR :

• 1) Verrouiller les identités : MFA + réduction des droits + détection d’anomalies sur exports.
• 2) Fermer les robinets de données : limiter exports, tracer, alerter sur volumes et comportements.
• 3) Encadrer les intégrations IA : scopes minimaux, pas de sur-partage de contexte, logs nettoyés.

Besoin d’un plan “réflexes fuite” orienté terrain PME/collectivité en AURA : https://lyon-ia.com/blog/fuites-de-donnees-8-mesures-immediates-pour-une-mairie-ou-une-pme-en-aura.

Et si votre sujet du moment, c’est l’hygiène webapp côté dev (notamment écosystème PHP très présent sur le tissu local), ce guide est un bon point d’entrée : https://lyon-ia.com/blog/vulnerabilites-php-auditer-et-securiser-tes-applis-web-a-lyon-sans-tout-arreter.

Sources

• CERT-FR (ANSSI), RETEX violations de données via applications web, publié le 20 octobre 2026 : https://cert.cyber.gouv.fr/cti/CERTFR-2026-CTI-008/?utm_source=openai
• Cybermalveillance.gouv.fr, étude maturité cyber TPE-PME 2025 : https://www.cybermalveillance.gouv.fr/tous-nos-contenus/actualites/etude-maturite-cyber-tpe-pme-2025?trk=public_post_comment-text&utm_source=openai
• Ma Sécurité (Ministère de l’Intérieur), violations de données : https://www.masecurite.interieur.gouv.fr/fr/fiches-pratiques/numerique/comment-reagir-face-violations-donnees?utm_source=openai
• ANSSI, recommandations AI coding assistants : https://cyber.gouv.fr/nous-connaitre/publications/publications-internationales/ai-coding-assistants/?utm_source=openai