Pour qui

Pentesteurs et chasseurs de bug bounty qui veulent passer des tests en boîte noire au code source.
Ingénieurs en sécurité applicative qui ont besoin d’une méthode de revue reproductible et d’aide pour trier les résultats des scanners.
Développeurs seniors et tech leads qui relisent des pull requests et veulent repérer les failles de sécurité avant le merge.

Ce que vous saurez faire

Cartographier un dépôt inconnu : points d’entrée, frontières de confiance et code qui mérite votre temps.
Suivre une entrée non fiable de sa source jusqu’au point d’usage dangereux, et distinguer une vraie vulnérabilité d’un faux positif de scanner.
Trouver les failles d’authentification, d’autorisation, de cloisonnement entre clients et de logique métier que les outils manquent.
Prouver l’exploitabilité dans un lab local et justifier la criticité en des termes qu’un responsable produit accepte.
Trouver les variantes d’une vulnérabilité connue grâce à l’analyse de correctifs et à des requêtes Semgrep ou CodeQL sur mesure.
Rédiger des vulnérabilités avec leur cause racine, leurs preuves et leur correctif, et vérifier si un correctif proposé tient.

Prérequis

Vous lisez couramment du code dans au moins un de ces langages : JavaScript/TypeScript, PHP, Java ou Python.
Vous connaissez HTTP et les grandes classes de vulnérabilités web, au niveau de l’OWASP Top 10.
Vous savez utiliser git, Docker et un terminal, et pouvez suivre une formation en anglais. Nous commençons par une courte évaluation de votre niveau pour adapter le parcours.

Programme

Huit modules. Votre parcours les suit dans l’ordre et avec la profondeur qui conviennent à votre niveau : vite sur ce que vous savez, plus longuement là où vous en avez besoin.

01Lire une base de code inconnue sous l’angle de la sécuritéTransformez un dépôt que vous n’avez jamais vu en carte de ce qu’un attaquant peut atteindre.
- Points d’entrée : routes, contrôleurs, tâches, webhooks et consommateurs de messages
- Conventions de framework qui masquent le routage et les middlewares
- Un modèle de menaces sur une page : actifs, acteurs et frontières de confiance
- Consacrer une revue au temps limité aux zones à risque
02Sources, puits et flux de donnéesSuivez l’entrée non fiable jusqu’à l’endroit où elle fait des dégâts.
- Traçage manuel de la source au puits, y compris les flux de second ordre
- Validation, assainissement et encodage, et quand chacun protège
- Puits SQL, commandes, templates, chemins de fichiers, SSRF et désérialisation
- Trier les résultats SAST : confirmer, écarter ou creuser
03Authentification et sessionsExaminez le code qui décide de l’identité de l’utilisateur.
- Parcours de connexion, d’inscription, de réinitialisation du mot de passe et de MFA
- Cycle de vie des jetons et des sessions : émission, validation, expiration, révocation
- Erreurs de vérification JWT, avec la chaîne de correctifs de fast-jwt comme cas d’étude
- Contrôles de redirection, de state et d’audience dans OAuth et OpenID Connect
04Autorisation et cloisonnement entre clientsTrouvez le contrôle manquant qui permet à un client d’atteindre les données d’un autre.
- Contrôles au niveau des objets et des fonctions (BOLA, BFLA, IDOR) dans les handlers, les middlewares et les requêtes ORM
- Mass assignment et over-posting
- Cloisonnement par client dans les requêtes, les caches et les tâches de fond
- Resolvers GraphQL et endpoints d’administration
05Logique métier, état et concurrenceTrouvez le code qui enfreint les règles dont dépend le produit.
- Invariants : ce qui doit toujours être vrai, et le code qui le casse
- Situations de concurrence dans les paiements, les coupons et les quotas
- Faire confiance aux prix, rôles et identifiants envoyés par le client
- Arithmétique : dépassement, troncature et largeur de décalage (CVE-2025-37858)
06Parseurs, plateformes et chaîne d’approvisionnementExaminez les hypothèses que votre code fait sur tout ce qui l’entoure.
- Normalisation des chemins et divergences entre parseurs (CVE-2026-21589, CVE-2026-104935)
- Contrôles qui disparaissent après une recherche infructueuse (CVE-2024-26855)
- Frontières du rendu côté serveur après React2Shell
- Dépendances, scripts de build et lockfiles après la compromission d’Axios sur npm
07Prouver l’exploitabilité et l’impactPassez d’une ligne suspecte à une vulnérabilité confirmée et priorisée.
- Préconditions, atteignabilité et contrôle de l’attaquant
- Une preuve minimale dans un lab local
- Criticité avec le CVSS et le contexte métier
- Analyse de correctifs et de variantes avec Semgrep et CodeQL
08Correctifs, rapports et code écrit par l’IAFaites corriger la vulnérabilité, et faites en sorte qu’elle le reste.
- Des vulnérabilités que les développeurs acceptent : emplacement, cause racine, preuves, correctif
- Examiner un correctif proposé et son test de non-régression
- Des réglages par défaut sûrs qui éliminent toute une classe de bogues
- Relire du code généré par l’IA, et vérifier ce que vous dit un relecteur IA

Travaux pratiques

Labs de traçage

Des revues guidées d’applications préparées pour la formation, où vous suivez l’entrée dans le vrai code du framework jusqu’à la ligne vulnérable.

Chasse aux variantes

Partez d’un correctif publié dans un projet open source, puis cherchez la même erreur ailleurs dans ce code, dans la version vulnérable.

Revue de correctifs

Déterminez si un correctif proposé supprime la cause racine ou seulement le symptôme signalé, et écrivez le test qui le prouve.

Évaluation finale

Auditer une application multi-clients

Une revue au temps limité d’une application conçue pour la formation, avec son code source et une copie en fonctionnement. Vous rédigez un rapport professionnel de vulnérabilités, que nous passons en revue ensemble lors d’une dernière séance.

Critères d’évaluation

Cartographie de couverture des points d’entrée et des frontières de confiance
Vulnérabilités confirmées avec preuves et étapes de reproduction
Cause racine correcte pour chaque vulnérabilité
Un raisonnement sur la criticité qu’un responsable produit peut suivre
Des correctifs qui traitent la cause, avec un test
Peu de faux positifs, clairement séparés des questions ouvertes

Ce qui distingue cette formation

Un apprenant, un formateur

Chaque séance se fait avec moi, et le parcours suit votre progression plutôt qu’un emploi du temps collectif.

De vrais cas, pas des exemples artificiels

Vous examinez le code de vulnérabilités publiées, dont certaines que j’ai analysées ou corrigées moi-même, ainsi que des applications préparées pour la formation.

La méthode avant les outils

Les scanners sont abordés pour ce qu’ils font bien. Vous apprenez à juger leurs résultats et à trouver ce qu’ils ne savent pas modéliser.

Outils utilisés

ripgrep
VS Code
git log / blame / diff
Semgrep
CodeQL
Docker
Burp Suite Community / Caido
Debugger

Normes et références

Études de cas à lire dès maintenant

Questions sur cette formation

Quels langages de programmation dois-je connaître ?

Les labs utilisent TypeScript/Node.js, PHP et Java, avec du C pour les études de cas en code natif. Vous devez lire couramment l’un d’eux ; la méthode se transpose d’un langage à l’autre, et nous nous y exerçons.

Combien de temps cela prend-il ?

Cela dépend de votre niveau de départ et du temps dont vous disposez entre les séances. Nous fixons un parcours après l’évaluation initiale et l’ajustons au fil de votre progression.

Est-ce la même chose qu’une préparation à l’OSWE ?

Non. L’OSWE certifie l’exploitation en boîte blanche par un examen. Cette formation enseigne une méthode de revue, l’analyse des causes racines et la qualité des correctifs, avec un accompagnement personnel. Beaucoup de compétences se recoupent, et la formation prépare bien à tout travail en boîte blanche.

Ai-je besoin d’un scanner commercial ?

Non. Toute la formation fonctionne avec des outils gratuits et open source.

Quand puis-je commencer ?

Envoyez un court message sur votre niveau et vos objectifs. Je réponds sous trois jours pour fixer un appel d’évaluation gratuit de 20 minutes ; nous convenons ensuite de votre programme et de votre date de démarrage.

Combien cela coûte-t-il ?

Chaque formation coûte 1 490 USD pour une dizaine de séances individuelles de 90 minutes, avec labs, correction des exercices, évaluation finale et attestation. Les deux formations ensemble coûtent 2 690 USD, et une séance à l’unité de 90 minutes coûte 150 USD.

Comment se déroule la formation individuelle ?

Nous nous retrouvons en ligne pour des séances en direct. Entre deux séances, vous travaillez sur les labs et les exercices que je vous donne selon votre niveau, et nous passons vos résultats en revue à la séance suivante. Le rythme suit votre progression, pas un calendrier figé.

Dans quelle langue se déroulent les séances ?

En anglais pour les apprenants internationaux. Les arabophones peuvent choisir l’arabe ou l’anglais ; les séances en arabe conservent les termes anglais que vous verrez dans les outils, les rapports et les offres d’emploi.

Y a-t-il des séances en présentiel ?

Non. Toutes les séances, les labs, les exercices et les retours se font en ligne.

Vais-je recevoir une attestation ?

Vous recevez une attestation de fin de formation lorsque vous réussissez l’évaluation finale. Elle est délivrée par moi et ne constitue pas une certification reconnue par la profession comme l’OSWE. Ce qu’un employeur peut vérifier, c’est le travail lui-même : votre rapport final.

Les exercices pratiques sont-ils légaux ?

Oui. Tous les travaux pratiques portent sur des applications que j’ai préparées pour la formation et sur des projets open source dans des versions ayant fait l’objet d’avis publiés, exécutés sur votre propre machine. Vous ne testez jamais un système qui ne vous appartient pas ou pour lequel vous n’avez pas d’autorisation écrite.

Et si j’ai besoin de plus de temps ?

Si vous avez besoin de plus de séances que prévu, chaque séance supplémentaire coûte 150 USD, et nous la convenons à l’avance.

Pour aller plus loin

Poursuivez avec la formation au test d’intrusion web et API appuyé sur le code.

Formation individuelle à la revue de code sécurisé