Une équipe de hackers contre votre app

Ce que c'est et pourquoi ça compte

Avant de lancer une app construite avec l'IA, la question est toujours la même : y a-t-il une faille que je ne vois pas ? Vous utilisez l'app de l'intérieur, avec votre compte, et elle marche. Celui qui veut la casser la regarde de l'extérieur.

Claude Security est un plugin officiel de Claude Code, et ce n'est pas un contrôle unique : c'est une équipe d'agents. L'un dessine la carte de votre architecture, un autre construit le modèle de menaces, c'est-à-dire qui attaquerait votre app, par où et pour prendre quoi, d'autres cherchent les vulnérabilités. Chaque faille trouvée est analysée par des agents vérificateurs indépendants avant d'entrer dans le rapport : le rapport reste court et sans fausses alertes. À la fin, il prépare les corrections sous forme de patchs, et c'est vous qui les appliquez.

Les hackers sont faux, au bon sens du terme : le plugin lit votre code, dans votre session, et n'attaque ni l'app en ligne ni la vraie base de données. Il s'adresse à ceux qui vont lancer une app contenant des données de personnes.

Son statut, vérifié dans la documentation officielle de Claude Code le 22 octobre 2026 : la page du plugin ne le présente ni comme un aperçu ni comme une bêta, et il s'installe depuis la marketplace officielle d'Anthropic. Ne le confondez pas avec le service géré du même nom qui surveille les dépôts en continu : c'est un produit à part, pour le plan Enterprise.

1. Ce qu'il vous faut

• Un forfait Claude payant, l'API d'Anthropic ou un fournisseur comme Amazon Bedrock, Google Cloud ou Microsoft Foundry. L'analyse utilise les workflows dynamiques de Claude Code, un script qui coordonne beaucoup d'agents en même temps. Avec le forfait Pro, vous les activez depuis /config, à la ligne Dynamic workflows.
• Python 3 accessible sous le nom python3 (essayez python3 --version). Le plugin n'utilise que la bibliothèque standard, n'installe rien, et si votre version est trop ancienne, son menu vous le dit.
• Git, pour n'analyser que vos modifications et pour les patchs. L'analyse complète fonctionne aussi sans. Mac, Linux ou Windows, tout convient.

Il n'y a pas de clé à part : le plugin n'appelle pas de modèles de lui-même, il utilise votre session, et les agents tournent sur le modèle choisi avec /model. Chaque analyse compte dans votre consommation, peut utiliser beaucoup de tokens et demande que Claude Code reste ouvert jusqu'à la fin.

2. Installez le plugin

Dans le dossier du projet, lancez Claude Code avec claude et tapez :

/plugin install claude-security@claude-plugins-official

La fiche du plugin s'ouvre, et vous choisissez pour qui l'installer : pour vous dans tous les projets, pour tout le monde sur le dépôt ou seulement pour vous dans ce dépôt. Si le résumé indique « Run /reload-plugins to apply. », tapez /reload-plugins. S'il vous dit au contraire que le plugin n'est pas dans la marketplace, rafraîchissez le catalogue avec /plugin marketplace update claude-plugins-official et réessayez.

3. Lancez l'analyse

1. Tapez /claude-security et choisissez Scan codebase.
2. Le plugin lit le dépôt et vous propose tout ou une partie, par exemple l'API ou la connexion, avec le nombre de fichiers et le coût relatif de chaque option. Si vous ne savez pas, répondez « I don't know » et il choisit pour vous.
3. Confirmez : rien ne démarre avant. Ensuite, laissez Claude Code ouvert. Le détail, agent par agent et avec les tokens de chacun, se trouve sous /workflows, d'où vous pouvez aussi tout arrêter.

Il fonctionne mieux en mode auto, où un second modèle examine les actions à votre place et où les agents ne vous demandent pas la permission à chaque étape. Sur un gros projet, allez zone par zone : connexion, paiements, API.

Seulement vos modifications, avant de fusionner

Si vous travaillez sur une branche, le menu vous propose de n'analyser que ce qui a changé par rapport à la base ; vous pouvez aussi demander un seul commit ou l'une de vos pull requests ouvertes. Seul ce qui est déjà commité compte. Vous pouvez aussi le demander avec des mots :

/claude-security analyse seulement les modifications de ma branche

4. Lisez le rapport

Chaque analyse écrit dans le dépôt un dossier CLAUDE-SECURITY-<horodatage>. C'est la seule chose qui change dans le projet, et il a son propre .gitignore, pour ne pas finir dans un commit par erreur. Dedans :

• CLAUDE-SECURITY-RESULTS.md, le rapport à lire : chaque faille a un identifiant (F1, F2…), son impact, un scénario d'attaque, la gravité, le niveau de confiance et ce qu'il faut faire.
• Les mêmes failles en .jsonl pour les programmes et en .sarif, le format standard que lisent GitHub code scanning et les autres outils de sécurité, avec la catégorie CWE de chaque faille.
• Un tampon, CLAUDE-SECURITY-REVISION-<commit>.json, qui indique quel commit a été analysé et avec quel effort, pour que chaque rapport reste lié au code qu'il décrit.

Commencez par les failles les plus graves avec une confiance élevée, et avant de corriger, faites-vous expliquer le scénario :

Ouvre le rapport de Claude Security et explique-moi la faille F1 comme si je ne connaissais rien à la sécurité : qui peut l'exploiter, ce qu'il obtient, par quel écran ou quelle adresse de l'app ça passe et quelle est la probabilité. Dis-moi si elle touche des données de vrais utilisateurs. Ne modifie rien.

5. Les corrections, c'est vous qui les appliquez

Tapez à nouveau /claude-security, choisissez Suggest patches puis les failles. Chaque patch est rédigé dans une copie à part du dépôt et relu par un autre agent, qui lance les tests s'il y en a. Il n'est livré que s'il ferme cette faille, n'en ouvre pas d'autres et ne change rien d'autre ; sinon, vous recevez une note qui explique pourquoi.

Les patchs arrivent dans patches/ à l'intérieur du rapport, un par faille (F1.patch, F2.patch…), et ne sont jamais appliqués automatiquement. Vous en appliquez un depuis le terminal comme ceci :

git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patch

Un patch par pull request, pour que chacun soit relu et testé séparément. Ou demandez-le à Claude :

Applique le patch F1 du rapport de Claude Security sur une nouvelle branche, lance les tests et ouvre une pull request avec seulement cette modification. Dans la description, écris la faille, la correction et comment tu l'as testée.

Si le code touché n'a pas de tests, la note du patch le dit : vérifiez-le à la main avant de fusionner. Et si ce code a changé entre-temps, la faille est sautée et le plugin vous propose une nouvelle analyse.

6. Les quatre failles typiques des apps construites avec l'IA

• La base de données ouverte. Supabase veut la Row Level Security sur chaque table exposée : sans elle, la clé publique de l'app peut suffire pour lire et écrire. Sur Firebase, cherchez allow read, write: if true, que la documentation dit de ne jamais utiliser en production. Le test en direct : guide PORTA (strikt.fit/porta).
• La clé secrète dans le code de l'app. Celle de Supabase (secret, ou service_role) jamais dans le navigateur, une app publiée ou sur GitHub. Et les variables VITE_, NEXT_PUBLIC_ et EXPO_PUBLIC_ finissent dans le code qui arrive au navigateur ou à l'app : pas de clés là-dedans. Guide CHIAVI (strikt.fit/chiavi).
• L'endpoint qui ne vérifie pas qui demande. Un endpoint est une adresse du serveur, comme /api/commandes/123. Le cas classique : il vérifie la connexion, mais pas que la commande 123 est à vous, alors vous changez le numéro et vous lisez celle de quelqu'un d'autre. C'est le premier risque de l'OWASP API Security Top 10 de 2023. Le contrôle se fait sur le serveur, pas dans un bouton caché.
• Aucune limite aux requêtes. Si un endpoint appelle une IA ou envoie des e-mails ou des SMS, n'importe qui l'appelle mille fois et c'est vous qui payez : c'est le quatrième risque de la même liste. Guide LIMITE (strikt.fit/limite).

Pour un premier coup d'œil rapide, avant la vraie analyse :

Vérifie dans le code de cette app les quatre failles classiques des apps construites avec l'IA et, pour chacune, donne-moi fichier, ligne et gravité : 1) tables de la base de données sans règles d'accès (Row Level Security sur Supabase, règles de sécurité sur Firebase) ou avec des règles qui laissent tout lire à n'importe quel utilisateur connecté ; 2) clés secrètes dans le code qui arrive au navigateur ou à l'app, y compris les variables NEXT_PUBLIC_, VITE_ et EXPO_PUBLIC_ ; 3) endpoints qui ne vérifient pas qui fait la requête ni si l'objet demandé lui appartient ; 4) endpoints sans limite de requêtes, surtout ceux qui coûtent de l'argent (IA, e-mail, SMS). Ne modifie rien et n'affiche jamais la valeur des clés.

C'est un seul passage, sans les vérificateurs du plugin. Et les règles de la base de données créées depuis le tableau de bord, et non dans le code, ni ce contrôle ni le plugin ne les voient : pour celles-là, il faut le test en direct.

Les erreurs les plus courantes

• Commencer par tout un gros dépôt. La première fois, choisissez une zone, comme la connexion ou l'API, et regardez ce qu'elle consomme dans /workflows.
• Demander l'analyse des modifications alors que le travail n'est pas encore commité. Elle ne regarde que les commits.
• Appliquer tous les patchs d'un coup. Un par pull request, chacun relu et testé.
• Prendre une analyse propre pour une app sûre. Les analyses varient d'un passage à l'autre et lisent le code, pas les réglages en ligne : refaites-les et faites aussi les tests en direct.
• Retirer du code une clé secrète trouvée et s'arrêter là. Il faut la révoquer et la remplacer, car elle reste dans l'historique.

Check-list

• Forfait payant ou API, workflows dynamiques activés (sur Pro, depuis /config).
• python3 et git fonctionnent, plugin installé.
• Première analyse sur une zone avec des données de personnes : connexion, paiements, API.
• Rapport lu en commençant par les failles les plus graves.
• Patchs appliqués un par pull request, ceux sans tests vérifiés à la main.
• Les quatre failles typiques vérifiées aussi en direct.
• Analyse refaite avant chaque lancement important.

Questions fréquentes