Un audit comme un autre, puis tout bascule
Lundi matin. On est mandatés pour auditer le portail d’une startup française d’InsurTech. Le produit : un SaaS B2B utilisé par des courtiers en assurance pour gérer les dossiers de leurs clients (devis, contrats, bénéficiaires).
Ce genre de mission ne commence pas toujours comme on l’imagine. Avant même de tenter la moindre exploitation, on interroge notre outil interne de surveillance des fuites de données. Concrètement, cet outil analyse en continu les identifiants volés par les infostealers, ces malwares installés sur des postes personnels ou pros qui aspirent tout ce que le navigateur garde en mémoire : mots de passe sauvegardés dans Chrome, cookies de session, tokens d’authentification.
Autrement dit : il suffit qu’un seul courtier utilisateur de la plateforme ait eu son poste infecté un jour, et que son mot de passe InsurTech ait été sauvegardé dans son navigateur. Son identifiant et son mot de passe se retrouvent alors en clair sur des marketplaces criminelles qu’on surveille activement. Pas besoin que le courtier ait réutilisé ce mot de passe ailleurs. Pas besoin que la plateforme InsurTech ait été piratée. Juste du malware sur une machine.
Et c’est exactement ce qui arrive. Quelques minutes plus tard, on est authentifiés sur le portail sous l’identité d’un vrai courtier. Zéro vulnérabilité applicative touchée chez le SaaS. Juste un malware qui traînait sur un poste quelque part.
Premier enseignement, avant même de parler technique : la sécurité de votre service ne dépend pas uniquement de votre propre code. Elle dépend aussi, directement, de l’hygiène numérique de chaque utilisateur. Un poste infecté dans un cabinet de courtage, un mot de passe sauvegardé dans le navigateur, et un attaquant peut se connecter à votre plateforme comme si de rien n’était.
Une fois connectés, on explore et on liste les points d’entrée testables. En début d’après-midi, un paramètre attire notre attention : celui qui permet au courtier de consulter un dossier client. L’équipe de dev pensait ce traitement correctement contrôlé. Il ne l’est pas.
Quelques requêtes de test plus tard, le diagnostic tombe : une injection SQL classique. Le genre de faille qui figure dans l’OWASP Top 10 depuis sa toute première édition en 2003, et qui y est encore en 2026 sous la catégorie A03 – Injection. Pas une CVE exotique, pas un zero-day. Juste une erreur de code basique : la saisie de l’utilisateur n’est pas correctement filtrée avant d’atteindre la base.
Résultat : ce qui devait rester une simple consultation de dossier client nous permet, en exploitant la faille, de remonter toute la structure de la base. Identités des assurés, coordonnées, numéros de sécurité sociale, RIB pour les prélèvements, etc. En quelques heures, à partir d’un compte courtier obtenu via un infostealer, on passe d’un accès individuel à une compromission massive.
Ce même type de chaîne d’attaque, on l’a aussi documenté côté bancaire dans notre retour d’audit public sur 9bank.
Et contrairement à ce que beaucoup de dirigeants supposent, rien de tout ça n’est propre au secteur de l’assurance.
Mais au fait, qu’est-ce qu’une injection SQL ?
Prenons une analogie classique, celle du guichet de banque. Un client se présente au guichet et remplit un bordereau : nom, numéro de compte, opération demandée. Le guichetier prend le bordereau, le transmet au service des archives au sous-sol, qui exécute ce qui y est écrit.
Tout le système repose sur une hypothèse simple : le client n’écrit que ce qu’il est censé écrire, soit son propre numéro de compte et sa demande.
Maintenant, imaginez qu’un client malveillant n’écrive pas simplement “12345” dans la case “numéro de compte”, mais : « 12345, et tant que vous y êtes, remontez-moi aussi tous les comptes de l’agence ».
Le guichetier, dont le rôle est de transmettre et pas de relire, passe l’instruction aux archives. Les archives, qui font confiance au bordereau validé par le guichet, exécutent tout : la demande légitime et la commande glissée à l’intérieur.
C’est exactement ce qui se passe dans une injection SQL. Le guichetier, c’est le code de votre application. Les archives, c’est la base de données. L’attaquant glisse des commandes à l’intérieur de ce qui aurait dû être une simple donnée (un nom, un identifiant, un mot-clé de recherche), et le code applicatif, faute de vérifier ce qu’il transmet, laisse passer.
Et le plus frappant : la base de données fait correctement son boulot. Elle exécute les instructions qu’on lui donne. La faille n’est pas dans son comportement, elle est dans l’absence de contrôle à l’étape d’avant.
« Nous n’avons pas de données aussi sensibles » : pourquoi aucune entreprise n’est à l’abri
À ce stade, un dirigeant peut se dire : « Nos données ne sont pas aussi sensibles. Même en cas de fuite, l’impact serait limité pour nous et pour nos clients. »
C’est une erreur de raisonnement.
Le critère de vulnérabilité n’a rien à voir avec la sensibilité que vous accordez à vos données. Il dépend d’une question beaucoup plus simple : « est-ce que notre application web communique avec une base de données SQL ? ». Et la réponse, pour l’écrasante majorité des entreprises, c’est oui.
Quant à l’impact réel d’une fuite, il est presque toujours plus lourd qu’on ne l’imagine avant qu’elle arrive. Quelques exemples très courants :
- Un SaaS B2B dans n’importe quel autre vertical (FinTech, LegalTech, EdTech, outils RH, CRM). Le principe observé en ouverture se rejoue alors à l’inverse : si votre base fuite par injection SQL, ce sont vos identifiants qui se retrouvent à leur tour sur ces marketplaces criminelles et qui alimentent des campagnes de credential stuffing sur tous les autres services utilisés par vos clients. Vous devenez, sans le vouloir, le point de départ d’une chaîne de compromissions.
- Un intranet RH qui contient bulletins de salaire, numéros de sécu, évaluations annuelles : base idéale pour du chantage ou de l’usurpation d’identité.
- Une plateforme e-commerce avec historique d’achats, adresses, et parfois numéros de carte bancaire stockés à tort. Cas documenté publiquement : la CNIL a désigné comme « violation du trimestre » un incident où une injection SQL a permis de récupérer des numéros de cartes bancaires sur un site e-commerce (source CNIL).
- Un outil interne métier qui héberge contrats, négociations en cours, propriété intellectuelle.
Bref, dès qu’il y a une base de données SQL derrière une application, le risque existe. C’est la norme, pas l’exception.
Le credential stuffing, c’est quoi ? Les attaquants récupèrent des identifiants volés (sur des marketplaces criminelles, via des infostealers, ou suite à des fuites massives de services tiers). Ils les testent ensuite en masse sur d’autres services, pour trouver ceux où le même mot de passe a été réutilisé. Un seul mot de passe partagé entre plusieurs comptes, et c’est toute une cascade de compromissions qui se déclenche.
Le coût d’une fuite : RGPD, image, effet domino
Parlons chiffres. C’est probablement ce que votre investisseur ou votre comité de direction attend de vous.
Cadre réglementaire et tendance des sanctions
Les notifications de violations de données adressées à la CNIL ont atteint 5 629 en 2024, soit +20 % par rapport à 2023. Sur la même période, les incidents qui touchent plus d’un million de personnes ont doublé (rapport annuel 2024 de la CNIL, synthèse officielle sur vie-publique.fr). Les amendes suivent la même pente : le cumul des sanctions prononcées en France est passé de 55,2 millions d’euros en 2024 à 486,8 millions en 2025 (bilan officiel des sanctions 2025 – CNIL).
Le cadre, lui, existe depuis 2018 avec le RGPD : en cas de violation de données personnelles, notification à la CNIL sous 72 heures, et amendes pouvant atteindre 4 % du chiffre d’affaires annuel mondial ou 20 millions d’euros. C’est le plus élevé des deux qui s’applique.
Et quand les données concernées relèvent de la catégorie spéciale du RGPD (santé, orientation, opinions politiques, données biométriques), les exigences de sécurité sont renforcées.
Longtemps, ce plafond est resté abstrait. Plus maintenant. Quelques exemples récents :
- 27 M€ et 15 M€ pour Free et Free Mobile suite à une intrusion qui a compromis les données de 24 millions d’abonnés (CNIL).
- 5 M€ pour France Travail après une fuite touchant 36,8 millions de personnes (communiqué officiel CNIL, délibération SAN-2026-003 sur Légifrance).
Et un point clé pour notre sujet : la sécurité des données figure en 2025 parmi les trois principaux motifs de sanction prononcés par la CNIL (bilan officiel des sanctions 2025). Les défauts techniques récurrents dans ces décisions (authentification faible, contrôles d’accès trop larges, vulnérabilités applicatives) sont exactement la famille dans laquelle s’inscrit l’injection SQL.
L’impact d’image et la confiance client
Les sanctions CNIL sont publiques. Elles sont reprises par la presse spécialisée, parfois par la presse généraliste. Pour une entreprise B2B, ça se traduit par une perte de confiance mesurable, qui se concrétise souvent au moment du renouvellement des contrats. Pour un e-commerce ou un SaaS B2C, on voit le coût d’acquisition grimper et le taux de désabonnement s’accélérer.
Rappel sur l’effet domino : une fuite n’est jamais contenue à votre système. Les identifiants, e-mails et données personnelles exfiltrés alimentent dans les mois qui suivent des campagnes de credential stuffing, de phishing et d’usurpation d’identité dirigées contre vos clients et partenaires.
Pourquoi les injections SQL sont encore là en 2026
Objection qu’on entend souvent en comité de direction : « Nos équipes utilisent des technologies modernes qui promettent de gérer la sécurité. On est couverts. »
En réalité, c’est plus nuancé. Ces technologies couvrent effectivement une partie du risque, mais uniquement quand elles sont correctement utilisées. Plusieurs raisons expliquent pourquoi les injections SQL sont encore présentes en 2026 :
- Les protections par défaut ne couvrent pas tous les cas. Les technologies modernes protègent tant qu’on reste dans les usages courants. Mais dès qu’il faut construire une requête sur mesure pour un besoin métier (filtrage complexe, recherche avancée, logique spécifique), la protection saute. Et c’est fréquent en production.
- Le code legacy. Plein d’entreprises ont migré une partie de leur stack vers des frameworks modernes, mais conservent en production des modules plus anciens. Ceux-là, souvent, n’ont jamais été réaudités côté sécurité.
- Les dépendances tierces. Un plugin CMS mal maintenu, une lib obsolète, un outil interne hérité : autant de vecteurs d’injection hors du radar.
- Le biais de perception. Parce que le sujet « a l’air vieux », les équipes tech relâchent leur vigilance. Les tests dédiés aux injections disparaissent progressivement des pipelines CI, les revues de sécu se concentrent sur des vulnérabilités plus médiatisées, et le risque résiduel passe sous les radars. Nouveau venu dans ce biais : le vibe coding, cette pratique qui consiste à laisser un LLM générer du code sans relecture de sécurité approfondie. Les injections SQL y reviennent en force, et on y consacrera prochainement un article dédié.
La CNIL, consciente de cette persistance, a renforcé ses exigences en 2025 en imposant l’authentification à double facteur aux organismes qui détiennent des bases de plus de deux millions de personnes (consignes CNIL). Signal clair : le régulateur ne considère pas le sujet comme réglé.
Comment savoir si votre application est exposée
Trois approches, par ordre de rigueur croissante.
1. Les scanners automatiques. Utiles pour un premier filtrage, mais fondamentalement limités. Ils détectent les injections SQL évidentes, typiquement celles où la base renvoie un message d’erreur qui trahit la vulnérabilité. Ils passent à côté des injections plus discrètes (où la base ne renvoie rien de visible à l’attaquant, mais où l’information fuit par d’autres canaux comme le temps de réponse ou le comportement de l’appli), et surtout des chaînes d’exploitation qui combinent plusieurs vulnérabilités mineures. Ils ne comprennent pas non plus la logique métier de votre application.
2. La revue de code interne. Indispensable, mais les dévs cherchent généralement des bugs fonctionnels, pas des chemins d’attaque. Sans formation spécialisée en sécurité offensive et sans méthodologie dédiée, beaucoup de patterns vulnérables passent inaperçus, surtout dans le code hérité ou dans les dépendances tierces.
3. Le pentest manuel par un expert externe. Un pentester ne cherche pas juste la présence d’un pattern vulnérable. Il cherche un chemin de compromission complet. Il combine des vulnérabilités individuellement mineures pour atteindre un impact majeur. Il reproduit le raisonnement d’un attaquant motivé, exactement comme dans le cas de l’InsurTech au début de l’article.
La méthodologie d’un audit sérieux s’appuie sur deux référentiels publics : l’OWASP Application Security Verification Standard (ASVS) pour les critères de conformité, et l’OWASP Testing Guide pour les techniques d’audit. Ça garantit une couverture rigoureuse et reproductible.
Sur notre audit InsurTech, aucune de ces trois approches n’avait été menée sur le module concerné avant qu’on intervienne. La faille était là depuis plusieurs années.
Conclusion
Une injection SQL en entreprise, c’est une faille dite « basique » qui peut suffire à compromettre toute une base de données. Le problème n’est pas la rareté du vecteur d’attaque, il est largement connu et documenté depuis plus de vingt ans. Le vrai problème, c’est la rareté des vérifications rigoureuses pour s’assurer qu’on n’est pas concerné.
Si un investisseur, un partenaire ou votre comité de direction vous a demandé de faire auditer votre application web (en assurance, InsurTech, FinTech, SaaS B2B ou tout autre secteur), il a raison. On audite régulièrement des applis dont les équipes techniques pensaient être protégées. Et on trouve, presque systématiquement, quelque chose qui mérite correction.