Agents de sécurité IA

Ton app a des failles de sécurité. Toutes les apps en ont. La question, c'est de savoir si tu les trouves avant tes utilisateurs.

Voilà à quoi ressemble une faille en pratique. Quelqu'un s'inscrit sur ton app. Il explore. Il change un chiffre dans l'URL. Et soudain, il voit les données privées d'un autre utilisateur. Infos de facturation, documents sauvegardés, messages personnels. Pas parce que c'est un hacker. Juste parce que ton app ne l'en a pas empêché.

C'est le genre de bug que la plupart des SaaS livrent. Pas un hack façon film. Juste une règle manquante qui dit "tu peux voir uniquement tes propres données."

Cet article présente un système qui détecte ces bugs automatiquement. Deux commandes. Huit agents IA. La phase 1 trouve tout ce qui semble suspect. La phase 2 essaie vraiment de s'introduire et prouve quels problèmes sont réels. Seuls les bugs confirmés se retrouvent dans le rapport final.

Les cinq failles que la plupart des SaaS livrent

Ce sont les problèmes de sécurité les plus courants dans les apps créées par des solo founders, des indie hackers, et des vibe coders. Aucun ne nécessite des compétences en hacking pour être exploité. Un utilisateur curieux avec les outils de développement du navigateur peut en trouver la plupart.

1. Les utilisateurs peuvent voir les données des autres

Tu crées une table de base de données pour stocker les données utilisateurs. Profils, documents, paramètres, peu importe. Par défaut, la plupart des bases de données se fichent de qui demande les données. Si quelqu'un les demande, la base les envoie.

La solution est une règle qui dit "retourne seulement les lignes qui appartiennent à la personne qui demande." En termes de base de données, c'est ce qu'on appelle la sécurité au niveau des lignes. Pense-y comme un filtre qui ajoute automatiquement "WHERE user_id = la personne connectée" à chaque requête. Sans ça, n'importe quel utilisateur connecté peut demander les données de n'importe qui.

C'est la faille de sécurité la plus courante dans les SaaS. Un utilisateur change un ID dans l'URL ou ouvre les outils de développement de son navigateur, et il voit des choses qu'il ne devrait pas.

2. Quelqu'un contourne le login et frappe directement ton backend

Ton app a une page de connexion. Derrière elle, il y a des endpoints d'API qui récupèrent et modifient des données. Le frontend envoie toujours le token de connexion avec chaque requête. Donc tu supposes que chaque requête a un token valide.

Mais quelqu'un peut appeler tes endpoints d'API directement, sans utiliser ton frontend du tout. Il peut utiliser des outils comme curl ou Postman. Si ton backend ne vérifie pas un token de connexion valide à chaque requête, il est dedans. Sans connexion nécessaire.

3. Des clés secrètes exposées dans le navigateur

Ton app communique avec des services externes : processeurs de paiement, fournisseurs d'e-mail, API IA. Chaque service te donne une clé secrète. Certaines de ces clés sont sûres à exposer dans le navigateur (comme ta clé publiable Stripe). D'autres ne le sont pas (comme ta clé secrète Stripe, ta clé API d'e-mail, ou ta clé d'administration de base de données).

Si une clé secrète se retrouve dans ton code frontend, n'importe qui peut ouvrir les outils de développement du navigateur, la trouver, et l'utiliser. Il peut envoyer des e-mails depuis ton compte, débiter des cartes bancaires, ou accéder à ta base de données avec toutes les permissions d'administrateur.

4. Ton API révèle plus qu'elle ne devrait

Ton endpoint de profil utilisateur retourne les données de l'utilisateur pour que le frontend les affiche. Mais le backend retourne tout ce qui est dans la ligne de la base de données, pas seulement ce dont le frontend a besoin. E-mail, nom complet, IDs internes, statut d'abonnement, peut-être même des hachages de mots de passe.

Un utilisateur appelle ton API et récupère ses propres données. Bien. Mais la réponse inclut 15 champs supplémentaires que le frontend n'utilise jamais. Il connaît maintenant ta structure de données interne. Pire, si la faille n°1 est aussi présente, il peut récupérer ces informations détaillées pour chaque utilisateur de ton système.

Les messages d'erreur font aussi partie de ça. Quand quelque chose tourne mal, ton app pourrait retourner l'erreur brute de la base de données : "la colonne 'stripe_customer_id' n'existe pas dans la table 'users'." Ça dit exactement à un attaquant comment ta base de données est structurée.

5. Des règles de sécurité navigateur manquantes

Les navigateurs ont des fonctionnalités de sécurité intégrées, mais elles ne fonctionnent que si ton app les active. Ce sont des en-têtes HTTP que ton serveur envoie avec chaque réponse. Ils disent au navigateur des choses comme :

• "Ne laisse pas d'autres sites intégrer mon app dans une frame" (prévient le clickjacking)
• "Exécute seulement les scripts que j'ai explicitement approuvés" (prévient l'injection de code)
• "N'accepte que les requêtes de mon propre domaine" (prévient les attaques cross-site)

Sans ces en-têtes, ton app est exposée à des attaques que les navigateurs ont été conçus pour bloquer. La plupart des frameworks ne les activent pas par défaut.

Pourquoi les scanners de sécurité n'aident pas

Il existe des outils qui scannent ton code pour détecter des problèmes de sécurité. Le problème : ils signalent tout ce qui semble mauvais, même quand c'est bien.

Voici un exemple. Ton app a une tâche en arrière-plan qui traite les paiements. Les tâches en arrière-plan n'ont pas d'utilisateur connecté, donc elles ont besoin d'un accès administrateur à la base de données pour fonctionner. Un scanner voit "accès administrateur à la base de données" et le signale comme une vulnérabilité critique. Mais c'est correct. La tâche en arrière-plan a besoin de cet accès. C'est pas un bug, c'est comme la fonctionnalité fonctionne.

C'est ce qu'on appelle un faux positif. Le scanner a signalé quelque chose qui semble dangereux mais est en fait normal.

Dans un vrai scan, ça arrive constamment. Le scanner signale 87 problèmes. Tu les lis tous. 82 d'entre eux correspondent à des choses qui fonctionnent comme prévu. Les 5 vrais bugs sont noyés dans un tas de fausses alarmes, et tu ne peux pas distinguer lesquels sans une connaissance approfondie de ta propre codebase.

Le problème central : les outils de sécurité ne comprennent pas ta logique métier. Ils ne savent pas que ta tâche en arrière-plan a besoin d'un accès administrateur. Ils ne savent pas que ta table "ideas" est intentionnellement publique. Ils ne savent pas que ton flux d'onboarding utilise un pattern d'auth spécifique exprès. Ils voient juste des patterns qui semblent dangereux et les signalent.

La solution en deux phases

Le pipeline, c'est deux commandes slash Claude Code. Chacune lance une équipe d'agents IA qui travaillent en même temps.

.claude/
  commands/
    security.md          # Phase 1 : 5 agents scannent ton code
    pentest.md           # Phase 2 : 3 agents essaient de s'introduire
  agents/
    security-auditor.md  # Règles que tous les agents Phase 1 suivent
dev/
  reports/
    security/            # Rapports Phase 1
    pentest/             # Rapports Phase 2

Phase 1 (Reporters) : Cinq agents lisent ton code et vérifient les cinq failles ci-dessus. Chaque agent se concentre sur un domaine. Ils ont aussi accès à ta base de données en direct, pour vérifier ce qui est réellement déployé, pas seulement ce que le code dit. Résultat : un rapport listant tout ce qui semble suspect.

Phase 2 (Exploiteurs) : Trois agents essaient vraiment de s'introduire dans ton app en cours d'exécution. Ils lisent le rapport de la Phase 1 et tentent d'exploiter chaque découverte. Ils envoient de vraies requêtes, essaient de vraies attaques, et enregistrent ce qui se passe. S'ils n'arrivent pas vraiment à s'introduire, la découverte est marquée comme faux positif et supprimée. Résultat : un rapport validé où chaque découverte restante a des preuves attachées.

Le filtre entre les deux phases, c'est ce qui fait que ça marche. La Phase 1 attrape tout ce qui est suspect. La Phase 2 prouve ce qui est réel. Les fausses alarmes meurent en Phase 2 au lieu de te faire perdre du temps.

Phase 1 : cinq reporters

Chaque reporter est un agent IA qui se concentre sur un type de problème de sécurité. Ils tournent tous en même temps.

Auditeur d'accès à la base de données

Vérifie si les utilisateurs peuvent voir les données des autres. Se connecte à ta base de données en direct et examine les vraies règles d'accès, pas seulement le code. Trouve les tables où les données utilisateurs sont stockées mais sans règle "retourne seulement tes propres lignes". Vérifie aussi les fonctions de base de données qui ont plus de permissions qu'elles ne devraient.

Auditeur de validation des entrées

Vérifie chaque endroit où ton app accepte des entrées utilisateur. Quelqu'un peut-il taper du code dans un champ de formulaire et le faire exécuter ? Quelqu'un peut-il envoyer une chaîne soigneusement construite qui trompe ta base de données pour exécuter des commandes ? Quelqu'un peut-il téléverser un fichier avec un nom comme ../../etc/passwd et lire des fichiers qu'il ne devrait pas ? Cet agent teste tout ça.

Auditeur de connexion et de session

Vérifie si ton système de connexion est solide. Y a-t-il des endpoints qui devraient nécessiter une connexion mais ne le font pas ? Quelqu'un peut-il appeler ton API avec un faux token de connexion ou expiré et quand même entrer ? Un utilisateur ordinaire peut-il accéder à des fonctionnalités réservées aux admins en modifiant son token ? Y a-t-il quelque chose qui empêche quelqu'un d'essayer des milliers de mots de passe ?

Auditeur de fuite de données

Vérifie ce que ton app révèle. Les réponses d'API retournent-elles des champs supplémentaires que le frontend n'utilise pas ? Les messages d'erreur montrent-ils des détails internes de la base de données ? Y a-t-il des clés secrètes dans ton JavaScript frontend qui ne devraient pas y être ? Des données sensibles apparaissent-elles dans des URLs où l'historique du navigateur ou les logs du serveur peuvent les capturer ?

Auditeur de configuration

Vérifie les paramètres de sécurité de ton app. Les en-têtes de sécurité du navigateur sont-ils activés ? Ton app dit-elle aux navigateurs d'accepter des requêtes de n'importe quel site web (elle ne devrait pas) ? Tes cookies de connexion sont-ils configurés correctement ? Y a-t-il des vulnérabilités connues dans les packages dont dépend ton app ?

Les cinq tournent en même temps. Chacun envoie ses découvertes sous forme de texte. Aucun ne modifie ton code. Un orchestrateur lit tout et le combine en un seul rapport.

La clé pour moins de faux positifs : la conscience de la logique métier

C'est ce qui distingue ces agents d'un scanner de sécurité ordinaire.

Chaque codebase a des choses qui semblent mauvaises mais sont correctes. Les agents doivent le savoir à l'avance. Sinon ils les signaleront à chaque fois, comme n'importe quel autre scanner.

La définition de l'agent inclut une section appelée "Exceptions documentées." C'est une liste de patterns que les agents doivent reconnaître et ignorer. Des choses comme :

• Les tâches en arrière-plan qui ont besoin d'un accès administrateur à la base de données (il n'y a pas d'utilisateur connecté, donc l'accès admin est le seul moyen)
• Les tables qui stockent des données publiques et sont intentionnellement lisibles par tout le monde
• Les patterns d'auth qui récupèrent des infos utilisateur supplémentaires lors de l'inscription (nécessaire pour des choses comme obtenir le nom d'un utilisateur depuis Google)
• Les clés API publiques qui sont censées être dans le navigateur (comme ta clé de site pour la protection anti-bot)
• Les tables gérées par des services tiers (ton prestataire de paiement synchronise des données dans ses propres tables)

Chaque exception est spécifique : quand le pattern apparaît, pourquoi c'est correct. L'agent vérifie sa liste d'exceptions avant de générer une découverte. Si un pattern correspond, il l'ignore. Pas de fausse alarme.

Cette liste est la chose la plus efficace que tu puisses écrire. Commence avec 5 à 10 entrées. Après chaque audit, ajoute les faux positifs qui passent. Au bout du troisième run, les agents éliminent 90%+ du bruit avant qu'il t'atteigne.

Les agents peuvent aussi se connecter à ta base de données en direct et vérifier ce qui est réellement déployé. Le code dit ce qui devrait être vrai. Une requête sur la base de données en direct montre ce qui est vrai. Si un script de migration était censé ajouter des contrôles d'accès à une table mais a échoué silencieusement, la requête en direct le détecte. Ça supprime toute une catégorie de faux positifs : les choses où le code semble bien mais le déploiement ne correspond pas.

Périmètre : ne vérifier que ce qui a changé

Faire tourner cinq agents sur toute ta codebase à chaque fois est coûteux. La plupart du temps, tu as seulement besoin de vérifier ce qui a changé depuis le dernier rapport.

La commande gère ça automatiquement. Elle regarde la date du dernier rapport de sécurité, trouve tous les fichiers qui ont changé depuis, et envoie seulement ces fichiers aux agents. Si rien de pertinent pour la sécurité n'a changé, elle s'arrête tôt.

Les scans complets sont pour le premier audit ou après un gros refactoring. Tout le reste est limité aux changements récents.

Phase 2 : trois exploiteurs

La Phase 2 lit le rapport de la Phase 1 et essaie vraiment de s'introduire dans ton app en cours d'exécution. Le serveur de dev doit tourner. Ces agents font de vraies requêtes et essaient de vraies attaques.

Exploiteur d'API

Appelle tes endpoints backend directement. Essaie les attaques de la faille n°1 (changer les IDs pour accéder aux données d'autres utilisateurs), la faille n°2 (appeler des endpoints sans token de connexion), et la faille n°3 (envoyer des caractères spéciaux qui pourraient tromper la base de données). Enregistre chaque requête et réponse comme preuve.

Exploiteur de navigateur

Ouvre ton app dans un navigateur et essaie les attaques des failles n°4 et n°5. Tape du code dans des champs de formulaire pour voir s'il s'exécute. Vérifie si ton app peut être intégrée dans la page d'un autre site web (ce qui pourrait tromper les utilisateurs pour qu'ils cliquent sur des choses). Copie un token de connexion, se déconnecte, et essaie d'utiliser l'ancien token pour voir s'il fonctionne encore.

Exploiteur de connexion

Se concentre entièrement sur ton authentification. Se connecte comme utilisateur ordinaire et essaie d'accéder aux fonctionnalités admin. Essaie de modifier le token de connexion pour changer l'ID utilisateur ou le niveau de permission. Envoie 50 tentatives de connexion rapides pour voir s'il y a une limitation du débit. Teste le flux de réinitialisation de mot de passe pour trouver des moyens de réutiliser des tokens.

Chaque découverte a besoin de preuves. La requête exacte envoyée et la réponse exacte reçue. Si un agent ne peut pas produire la preuve que l'attaque a fonctionné, la découverte est supprimée. C'est pourquoi la Phase 2 élimine les faux positifs : l'agent doit vraiment exploiter le bug, pas juste dire qu'il pourrait exister.

Le filtre en action

Dans un vrai audit d'une app SaaS en production, les chiffres ressemblaient à ceci :

Les 82 découvertes tuées étaient des choses comme : accès administrateur à la base de données dans une tâche en arrière-plan (correct), tables publiques sans règles d'accès par utilisateur (intentionnellement publiques), un pattern d'auth spécifique utilisé lors de l'inscription (nécessaire pour cette fonctionnalité), messages d'erreur verbeux qui n'apparaissent qu'en mode développement (pas en production).

Les 5 bugs confirmés étaient réels. Un permettait à n'importe quel utilisateur de se donner un accès admin en mettant à jour son profil. Un autre permettait à n'importe qui d'ajouter des crédits illimités à son propre compte. Un troisième était une redirection ouverte dans le flux de paiement qui pouvait envoyer les utilisateurs vers un faux site après le checkout. Chacun venait avec le changement de code spécifique pour le corriger.

Sans la Phase 2, tu obtiens 87 éléments sans savoir lesquels comptent. Avec la Phase 2, tu obtiens 5 éléments prouvés réels, avec les preuves d'attaque attachées.

L'exécution

Deux commandes :

/security

Phase 1. Cinq agents scannent en même temps. Par défaut, les changements depuis le dernier rapport. Le rapport se sauvegarde dans dev/reports/security/. Si des problèmes sérieux sont trouvés, il te dit de lancer la Phase 2.

/pentest

Phase 2. Lit le rapport de la Phase 1. Démarre ton serveur de dev s'il ne tourne pas déjà. Trois agents essaient de s'introduire en même temps. Le rapport validé se sauvegarde dans dev/reports/pentest/.

Règles pour construire ça toi-même

Le pattern fonctionne avec n'importe quelle base de données, n'importe quel framework, n'importe quel fournisseur d'auth. Voilà ce qui le fait fonctionner.

Écris ta liste d'exceptions avant le premier scan. Chaque app a des choses qui semblent mauvaises mais vont bien. Les agents ont besoin de cette liste à l'avance. Commence avec les patterns que tu sais être corrects. Ajoute les faux positifs de chaque run. La liste se stabilise après 2 ou 3 audits.

Donne aux agents l'accès à la vraie base de données, pas juste au code. Le code dit ce qui devrait être vrai. La base de données en direct montre ce qui est vrai. Si ça ne correspond pas, tu as un problème que le code ne peut pas te dire.

Sépare la découverte de la preuve. Les agents de la Phase 1 signalent tout ce qui est suspect. Les agents de la Phase 2 essaient de l'exploiter. Mettre les deux jobs dans un seul agent crée un conflit. Il signale soit trop (bruyant) soit trop peu (rate des choses). Deux phases avec des jobs différents produisent de meilleurs résultats.

Exige des preuves, pas des opinions. Ne demande jamais à un agent "est-ce sécurisé ?" Demande-lui de montrer la requête et la réponse qui prouvent que l'attaque a fonctionné. Les preuves forcent une vraie vérification. Les opinions invitent aux raccourcis.

Chaque découverte a besoin d'un correctif. Pas "considère améliorer ta sécurité." La ligne spécifique à changer et ce qu'il faut y mettre. Une découverte sans correctif est une découverte qui reste dans un dossier pour toujours.

Inclus ce qui a fonctionné. Le rapport de la Phase 2 devrait lister les attaques qui ont échoué. Injection bloquée. Exécution de script bloquée. Requêtes cross-site bloquées. Savoir ce que ton app défend est aussi précieux que savoir ce qu'elle ne défend pas.

Au-delà de la sécurité

Le pattern en deux phases (trouver tout, puis prouver ce qui est réel) fonctionne pour plus que la sécurité.

Revue de code. Les agents de la Phase 1 signalent les problèmes potentiels. Les agents de la Phase 2 écrivent des tests qui échouent pour prouver que les problèmes sont réels. Les faux positifs tués de la même façon.

Performance. Les agents de la Phase 1 identifient les requêtes de base de données lentes et les gros bundles de fichiers. Les agents de la Phase 2 font tourner de vrais benchmarks. Une "requête lente" qui prend 2 millisecondes sur des données réelles n'est pas un vrai problème.

Conformité. Les agents de la Phase 1 signalent les patterns de gestion des données. Les agents de la Phase 2 tracent où les données circulent réellement pour vérifier si les signalements comptent. Une fonction qui traite des données d'analytique anonymes n'a pas besoin de gestion du consentement à la vie privée, même si le pattern ressemble à une qui en a besoin.

Même idée centrale à chaque fois. Donne aux agents assez de contexte pour comprendre pourquoi le code existe. Sépare la découverte de la preuve. Filtre le bruit avant qu'il t'atteigne.