Tu lances une commande, et une équipe d'agents IA attaque ton application comme le ferait un vrai hacker : ils exploitent réellement les failles, te prouvent qu'elles marchent, et te donnent le correctif. 🛡️
Ce guide n'est pas pour les grands débutants. Il faut être à l'aise avec un terminal, une clé API et Docker. Si tu vibe codes déjà et que tu déploies des projets en ligne, tu es exactement la bonne personne. Sinon, garde-le sous le coude et reviens quand tu auras un premier projet en prod.
Strix attaque réellement la cible que tu lui donnes. Ce n'est pas une simulation.
Tu ne peux l'utiliser que sur ce qui t'appartient, ou sur ce pour quoi tu as une autorisation écrite explicite. C'est la règle posée par les auteurs eux-mêmes :
« only run it against systems you own or have explicit, written permission to test […] Unauthorized testing is illegal in most jurisdictions. »
Scanner le site de quelqu'un d'autre, même « pour rendre service » ou « juste pour voir », est un délit en France comme dans la plupart des pays. Tu risques des poursuites, pas un avertissement.
Utilisé sur tes propres projets, c'est un outil de défense remarquable. Reste de ce côté-là.
| Le repo | github.com/usestrix/strix · 49 000 ⭐ |
| Licence | Apache 2.0 · open source |
| L'outil | Gratuit |
| Mais | il tourne sur ta clé API (Claude, GPT, Gemini…) → tu paies les tokens du scan |
| Ce que c'est | des agents IA autonomes qui font recon → exploitation → rapport |
| Ce que ce n'est pas | un scanner passif qui liste des « potentiels problèmes » |
Le repo, ses 49 000 étoiles et sa licence Apache 2.0 :
C'est toute la différence, et c'est ce qui rend l'outil utile :
| Un scanner classique | Strix |
|---|---|
| Liste des vulnérabilités potentielles | Exploite réellement la faille |
| Beaucoup de faux positifs | Une preuve de concept qui fonctionne |
| « Il y a peut-être une injection SQL ici » | « Voici la requête qui a extrait tes données » |
| À toi de trier | Étapes de reproduction + correctif fournis |
Tu ne récupères pas une liste à trier. Tu récupères la démonstration que la faille est réelle, et quoi écrire pour la fermer.
Une seule commande dans ton terminal :
curl -sSL https://strix.ai/install | bash
curl | bashCette commande télécharge un script et l'exécute directement. C'est pratique, mais tu exécutes du code sans l'avoir lu. Pour vérifier avant :
curl -sSL https://strix.ai/install | less
Tu lis, tu quittes avec q, puis tu relances avec | bash si ça te va. C'est un bon réflexe en général, et particulièrement sur un outil de sécurité.
Strix fait tourner ses agents dans des conteneurs Docker isolés (c'est ce qui protège ta machine pendant qu'il attaque). Si Docker n'est pas installé, l'outil te le demandera au lancement. Installe-le une bonne fois : 👉 docker.com/get-started, lance Docker Desktop, et laisse-le tourner en fond.
Strix ne fournit pas l'intelligence : tu lui branches le modèle que tu as déjà.
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="ta-cle-api"
Deux options utiles :
LLM_API_BASE → pour pointer vers un autre fournisseur (OpenRouter, modèle local…)STRIX_REASONING_EFFORT → règle la profondeur de réflexion des agentsGPT-5 ou Claude Sonnet marchent très bien, mais ils font grimper la facture. Tu peux brancher un modèle bien moins cher via OpenRouter — par exemple MiniMax M3 — et un scan complet (attaque + correctifs) peut te revenir à moins d'un dollar.
export STRIX_LLM="openrouter/minimax/minimax-m3"
export LLM_API_BASE="https://openrouter.ai/api/v1"
export LLM_API_KEY="ta-cle-openrouter"
C'est le meilleur rapport qualité/prix pour ce genre de scan : assez malin pour trouver et exploiter, sans te vider ton budget tokens.
L'outil est gratuit, mais chaque scan consomme des tokens sur ta clé. Un audit complet, ce sont des agents qui explorent, testent et réessaient pendant un moment — ça se compte en dollars, pas en centimes.
Commence par un petit projet pour mesurer, avant de lancer ça sur ton app principale. Et si tu veux garder ça à quelques centimes, utilise MiniMax M3 via OpenRouter (voir le tip juste au-dessus).
Avant de lâcher les agents, prends 5 minutes pour clarifier ta surface d'attaque. Plus tu sais ce que tu protèges, plus le scan est pertinent. Colle ce prompt dans ton Claude :
Je vais lancer un pentest automatisé (l'outil Strix) sur mon projet. Avant de le lancer,
je veux que tu m'aides à cadrer précisément ma surface d'attaque et mon besoin en sécurité.
Pose-moi un maximum de questions, une par une, sous forme de questions à choix (widgets),
pour clarifier :
- le type de projet (site vitrine, SaaS, e-commerce, API, app mobile)
- la stack technique (framework, base de données, hébergement)
- l'authentification (comptes, rôles, paiements, données sensibles stockées)
- ce qui est exposé publiquement vs ce qui est privé
- les intégrations tierces et les secrets / clés API en jeu
- ce qui me ferait le plus mal si ça arrivait (fuite de données, prise de contrôle, fraude)
Ne pose qu'une question à la fois et attends ma réponse. Quand tu as assez d'infos,
résume ma surface d'attaque en clair et dis-moi sur quoi concentrer le scan Strix en priorité.
Strix est autonome, mais il attaque mieux quand tu sais toi-même ce qui compte. Ce cadrage te donne aussi une checklist claire à vérifier une fois le rapport reçu.
Sur un projet local :
strix --target ./mon-projet
Sur un repo GitHub :
strix --target https://github.com/ton-compte/ton-repo
Les agents démarrent, explorent ton application, et tentent de vraies attaques sur ce qu'ils trouvent.
Bien au-delà du top 10 des vulnérabilités classiques :
| Catégorie | Exemples |
|---|---|
| Contrôle d'accès | IDOR, escalade de privilèges |
| Injections | SQL, NoSQL, commandes système, SSTI |
| Côté serveur | SSRF, XXE, exécution de code à distance |
| Côté client | XSS (toutes variantes), CSRF, prototype pollution |
| Logique métier | failles de raisonnement propres à ton app |
| Authentification | sessions, jetons, faiblesses de connexion |
| Infrastructure | mauvaises configurations |
| API | endpoints exposés, contrôles manquants |
La catégorie logique métier est celle qu'aucun scanner automatique ne trouve : ce sont les failles propres à ton application (« si je modifie ce paramètre, je passe la commande à 0 € »). Il faut comprendre le contexte, et c'est exactement ce que des agents savent faire.
Pour chaque faille trouvée, tu obtiens :
Donne le rapport à Claude Code avec ton projet ouvert et demande-lui d'appliquer les correctifs un par un. Tu passes de « je sais que je suis troué » à « c'est corrigé » dans la même session.
Et relance un scan après : c'est la seule façon de vérifier que le correctif tient.
Ça vaut le coup :
C'est moins utile :
C'est vraiment gratuit ? L'outil oui, entièrement open source. Mais il consomme les tokens de ta clé API. Compte quelques dollars par scan sérieux — ou zéro avec un modèle local.
Je peux scanner le site d'un client ? Uniquement avec son accord écrit, et dans le périmètre convenu. Sans ça, c'est illégal.
Ça peut casser mon site ? Les agents lancent de vraies attaques. Ne scanne jamais directement ta production. Fais-le en local ou sur un environnement de test.
Ça remplace un audit professionnel ? Pour un projet perso ou un petit SaaS, ça couvre énormément. Pour une app critique (santé, finance, données sensibles), ça complète un audit humain, ça ne le remplace pas.
Faut savoir coder ? Pour lancer, non — c'est une commande. Pour appliquer les correctifs, un peu, mais Claude Code le fait pour toi.
Et mes données ? Ton code est envoyé au modèle que tu branches. Si c'est sensible, utilise un modèle local via LLM_API_BASE.