Le guide d'installation de security-audit dans Claude Code : la commande, les phrases exactes à dire à Claude, comment lire le rapport, et comment faire corriger chaque faille confirmée sans rien casser.
Cet audit ne remplace pas un test d'intrusion fait par un professionnel si ton app gère des paiements ou des données sensibles. C'est un très bon premier filet, pas une garantie.
security-audit est une skill publiée par Cloudflare sur GitHub (cloudflare/security-audit-skill), sous licence MIT, donc gratuite. Elle avait 30 100 étoiles le 16 octobre 2026. Elle transforme Claude Code en auditeur de sécurité : il lit le code de ton app et cherche les vraies failles, celles qu'un attaquant pourrait exploiter.
Elle travaille en six phases. En clair :
Il repère tout ce qui entre dans ton app (formulaires, routes d'API, fichiers envoyés) et qui a le droit de faire quoi. Il l'écrit dans un fichier architecture.md.
Il envoie plusieurs agents, chacun sur sa zone : connexion, base de données, API, et l'injection de prompt si ton app utilise de l'IA.
Chaque faille trouvée passe à un nouvel agent, qui n'a qu'un seul but : prouver qu'elle n'existe pas. L'agent qui vérifie n'est jamais celui qui a trouvé.
Chaque piste reçoit un verdict et part dans un fichier findings.json.
D'autres agents, neufs, relisent les preuves des failles retenues.
Trois fichiers lisibles : REPORT.md, FINDINGS-DETAIL.md et NEEDS-VALIDATION.md.
Les trois verdicts, à connaître pour lire le rapport :
Je dis que le système construit à partir de cette skill a sorti plus de 7 000 problèmes à corriger. Le chiffre exact, dans l'article de Cloudflare du 18 juin 2026 (Build your own vulnerability harness), est 7 245, sur 128 de leurs propres dépôts : 20 799 pistes au départ, 12 057 qui ont passé la validation, 7 245 à corriger après dédoublonnage. C'est le résultat d'un système beaucoup plus gros, construit en partant de la skill (environ 450 lignes au début), pas d'un seul passage de la skill sur un projet. Plusieurs vidéos le racontent autrement.
Dans ton terminal, colle la commande de la vidéo. Je l'écris ici avec la forme courte de l'adresse du dépôt (cloudflare/security-audit-skill), qui fait exactement la même chose que l'adresse GitHub complète :
npx skills add \
cloudflare/security-audit-skill \
--skill security-auditL'outil te demande pour quel assistant l'installer : choisis Claude Code. Lancée dans le dossier de ton app, la commande installe la skill pour ce projet seulement. Pour l'avoir dans tous tes projets, ajoute --global :
npx skills add \
cloudflare/security-audit-skill \
--skill security-audit \
--globalPour vérifier qu'elle est bien là, tape npx skills list, ou demande simplement à Claude « Quelles skills as-tu ? ».
Ouvre Claude Code dans le dossier de ton app, puis dis-lui la phrase de la vidéo. Je la rends juste un peu plus précise :
Fais un audit de sécurité
complet de ce projet.La skill a deux modes. Par défaut, elle ne fait que conseiller : si tu demandes « est-ce que mon app est sécurisée ? », Claude te répond avec quelques pistes, sans lancer les six phases ni écrire de rapport. L'audit complet ne démarre que si tu le demandes en toutes lettres : « audit de sécurité », « audit complet », ou « test d'intrusion du code ». Si ta phrase est ambiguë, Claude te pose une question avant de commencer. Garde le mot audit et le mot complet.
Deux variantes utiles :
Fais un audit de sécurité
complet du dossier ./src
uniquement.
Fais un audit de sécurité
rapide de ce projet (profil
quick), limité à 20 agents.Le rapport n'atterrit pas dans ton projet : il va par défaut dans ~/security-audit-skill/<nom-du-projet>/run-1 (puis run-2, run-3…). C'est voulu, pour ne jamais mettre un rapport de failles dans ton dépôt Git. Si tu lui demandes de l'écrire dans ton projet, il refuse, sauf si le dossier est ignoré par Git.
Ouvre les fichiers dans cet ordre :
Le résumé. En haut, ce qui a été couvert et ce qui ne l'a pas été. Puis un tableau des failles confirmées : gravité, titre, partie de l'app touchée, et ce qui a été observé. Pour chacune, la correction la plus petite possible.
Le détail des failles moyennes, hautes et critiques : le chemin exact dans le code, comment la reproduire sans danger, et le test qui prouvera qu'elle est fermée.
Les pistes à vérifier, avec pour chacune le fait précis qui manque.
Comment la gravité est calculée : la probabilité qu'on l'exploite multipliée par l'impact réel. Pas « ça ne respecte pas une bonne pratique ».
Une note de durcissement n'est pas une faille. Si une protection bloque déjà l'attaque, l'absence d'une deuxième protection est rangée à part, dans les notes de durcissement. Tu peux t'en occuper plus tard.
« needs_validation » n'est pas un échec. Pour prouver certaines failles, il faudrait faire tourner ton code dans un bac à sable fermé (sans Internet, avec des limites strictes). Si ta machine ne le fournit pas, la skill refuse d'exécuter ton code et laisse la piste ouverte, avec ce qu'il faut vérifier. Souvent, c'est un réglage de ton hébergeur qu'elle ne peut pas voir dans le code. Pour t'en occuper :
Pour chaque piste de
NEEDS-VALIDATION.md, explique-
moi en une phrase ce qu'il
faut vérifier, et comment je
le vérifie moi-même, sans
risque.Dans la vidéo, je dis : « Corrige les failles confirmées, une par une. » Voici la version complète, à copier :
Pour chaque faille confirmée
du rapport, une par une :
explique-la-moi simplement,
corrige-la, ajoute un test qui
prouve qu'elle est fermée, et
attends mon accord avant de
passer à la suivante.Pourquoi le test compte : sans lui, Claude « corrige » parfois sans rien prouver. Le test fait échouer l'ancienne version et réussir la nouvelle. S'il réussit avant la correction, c'est que la correction ne vise pas le bon endroit.
Une fois tout corrigé, relance un audit : c'est lui qui confirme que les failles sont fermées.
C'est l'information la plus utile du dépôt, et personne n'en parle : d'après les tests de Cloudflare, un seul passage trouve environ la moitié des failles que trouvent plusieurs passages réunis. Et les passages s'additionnent : le suivant relit les rapports d'avant et vise ce qui n'a pas été couvert.
Relance l'audit sur ce même
projet en t'appuyant sur le
rapport précédent, et vise ce
qui n'a pas encore été couvert.Mon conseil : un premier audit, les corrections, puis un deuxième audit. Un troisième si ton app manipule de l'argent ou des données personnelles.
Un audit complet lance beaucoup d'agents en parallèle : il prend du temps et consomme vite ta limite d'usage de Claude. Trois façons de garder la main :
quick pour un premier coup d'œil ou un petit projet, standard par défaut, deep pour un gros projet sensible. Dis-le dans ta phrase../src, puis le reste.Un passage quick ou limité à un dossier est annoncé comme partiel dans le rapport : il ne dit jamais « le reste est sain ».
« Mon app est sécurisée ? » donne des conseils, pas un audit. Dis « audit de sécurité complet ».
Un seul passage trouve environ la moitié des failles. Relance après les corrections.
Une faille à la fois, avec un test, et ton accord entre chaque. Sinon tu ne sais plus ce qui a cassé quoi.
Les notes de durcissement et les pistes à vérifier ne sont pas des failles confirmées. Commence par le tableau des failles confirmées.
Il décrit comment attaquer ton app. Ne le partage pas, ne le mets pas dans ton dépôt, et efface-le quand tout est corrigé.