Docs/Pour les apprenants/Mode pratique

Mode pratique

Le Mode pratique présente des challenges de revue de code où vous identifiez le code vulnérable et sélectionnez le correctif approprié. Disponible sur plus de 200 sujets couvrant OWASP Top 10 (Web), OWASP API Top 10, OWASP Mobile Top 10 et OWASP Client-Side Top 10 — dans plusieurs langages.

Comment ça fonctionne

Chaque challenge suit un système en deux phases conçu pour tester vos compétences de détection de vulnérabilité et de remédiation :

Phase 1 — Trouver la vulnérabilité

Lisez un extrait de code et identifiez quel bloc contient la vulnérabilité de sécurité. Cliquez sur le bloc correct parmi plusieurs options mises en évidence pour avancer.

Phase 2 — Sélectionner le correctif

Une fois la vulnérabilité identifiée, choisissez le correctif approprié parmi plusieurs options. Chaque option semble plausible, mais une seule traite correctement le problème de sécurité.

Notation : Chaque challenge vaut jusqu'à 200 XP — 100 XP pour chaque phase avec une bonne réponse au premier essai. Les essais répétés et l'utilisation d'indices réduisent le score par phase (voir Notation et XP ci-dessous).

Interface du challenge

Voici à quoi ressemble un challenge typique de revue de code :

app.securecodinghub.com/topic/sql-injection/challenge/0
1
Trouver la vulnérabilité
2
Choisir le correctif
3
Terminé
0XP
Risque élevé

SQL Injection in user lookup

backend / python / web

Scénario

Un point de terminaison de détail utilisateur prend id depuis la chaîne de requête et l'utilise pour récupérer la ligne correspondante. L'un des blocs candidats ci-dessous fait confiance à cette valeur alors qu'il ne devrait pas.

PYTHONviews.py
12def get_user(request):
13 user_id = request.GET['id']
14 query = "SELECT * FROM users WHERE id=" + user_id
15 cursor.execute(query)
16 return JsonResponse(cursor.fetchone())
Les blocs mis en évidence sont des candidats — choisissez celui qui est vulnérable.

Choix de votre langage

Chaque sujet propose des challenges dans plusieurs langages de programmation. Votre préférence technologique détermine quel langage est affiché par défaut — les développeurs backend voient les challenges Python, Java ou Go, tandis que les développeurs frontend voient React, Vue ou Angular.

Vous pouvez basculer entre les langages à tout moment via le sélecteur de langage. Votre préférence est enregistrée pour que vous voyiez toujours les challenges dans votre stack préférée en premier.

JavaScript
TypeScript
Python
Java
C#
PHP
Go
React
Vue
Angular
Swift
Kotlin

Utilisation des indices

Chaque phase a son propre bouton d'indice. L'utilisation d'un indice divise par deux le score que vous gagnez pour cette phase, avec un plancher de 10 XP — donc une phase propre au premier essai valant 100 XP devient 50 XP si vous avez utilisé l'indice, et une phase au deuxième essai valant 60 XP devient 30 XP. Les indices fournissent une orientation ciblée sans donner la réponse — ils vous orientent dans la bonne direction tout en exigeant que vous réfléchissiez de manière critique.

Les indices sont optionnels. Ils sont particulièrement utiles lorsque vous rencontrez un type de vulnérabilité inconnu pour la première fois.

Notation et XP

Chaque phase est notée indépendamment. Une bonne réponse au premier essai rapporte l'XP complète de la phase ; les mauvais essais répétés et l'utilisation d'indices la réduisent tous les deux.

Résultat de phaseSans indiceAvec indice
Correct au 1er essai100 XP50 XP
Correct au 2e essai60 XP30 XP
Correct au 3e essai ou après30 XP15 XP
Maximum par challenge (les deux phases au premier essai, sans indice)200 XP

La réduction d'indice est une coupe de 50 % avec un plancher de 10 XP, donc même une phase au 3e essai avec un indice rapporte au moins 10 XP. Les deux phases tournent indépendamment — un indice ou un mauvais essai en Phase 1 n'affecte pas la Phase 2.

Ce qui se passe quand vous vous trompez

Le premier mauvais essai dans l'une ou l'autre phase vous invite à réessayer sur le même code. Après le deuxième mauvais essai en Phase 1, un court dialogue narratif apparaît expliquant les conséquences réelles de la vulnérabilité que vous avez manquée avant de vous laisser réessayer. Il n'y a pas de plafond d'essais — vous pouvez continuer à réessayer, mais chaque essai supplémentaire au-delà du troisième plafonne la phase à 30 XP.

Complétion du challenge

Après avoir terminé les deux phases, vous voyez une ventilation du score :

app.securecodinghub.com/topic/sql-injection/challenge/0
Challenge terminé
+200 XP
Phase 1 — Trouver la vulnérabilité100 / 100
Phase 2 — Choisir le correctif100 / 100
Étapes suivantes : Explorez le Mode apprentissage pour des parcours interactifs de scénarios d'attaque, ou plongez directement dans la pratique depuis le tableau de bord.

Lire le flux Phase 1 vers Phase 2

La structure en deux phases existe parce que la détection de vulnérabilité et la remédiation sont deux compétences différentes. La Phase 1 entraîne votre œil : étant donné une fonction ou méthode complète, quelle ligne est dangereuse. On ne vous demande pas d'écrire du code ; on vous demande de le lire comme le ferait un relecteur. La ligne vulnérable est rarement la plus intéressante syntaxiquement. C'est généralement une ligne discrète qui fait quelque chose qu'un développeur écrirait sans réfléchir, comme concaténer un paramètre de requête dans une chaîne qui sera analysée plus tard.

La Phase 2 entraîne votre jugement. Une fois que vous savez où est le problème, la plateforme vous montre plusieurs correctifs plausibles. La plupart compilent, s'exécutent et semblent raisonnables. Un seul ferme complètement la vulnérabilité. Certaines options corrigent le symptôme évident tout en laissant la primitive sous-jacente intacte. Certaines options surcorrigent et cassent la fonction. L'objectif de la Phase 2 est de vous faire raisonner sur pourquoi un correctif fonctionne, pas seulement s'il semble plus sûr que l'original. Traitez les mauvaises réponses comme un guide d'étude : chacune est une vraie erreur que de vrais développeurs font dans de vraies pull requests.

Pourquoi deviner ruine la courbe d'apprentissage

Le système d'indices divise par deux l'XP d'une phase (avec un plancher de 10 XP), ce qui sonne comme une pénalité mais est structuré comme un échange. L'échange est une orientation significative contre un score plus bas. Deviner sans indice vous coûte la même XP et ne vous apprend rien, car la boucle de retour est trop grossière pour apprendre. Si vous vous retrouvez à lire l'extrait pendant moins de trente secondes avant de cliquer, vous devinez presque certainement. Ralentissez, lisez l'extrait deux fois, formulez une hypothèse sur l'emplacement de la limite de confiance, puis cliquez.

Le bon rythme pour une nouvelle classe de vulnérabilités est de lire attentivement, d'utiliser l'indice quand vous êtes bloqué, et d'accepter la réduction de score comme le coût de l'apprentissage. Après trois ou quatre challenges dans la même classe, vous cessez d'avoir besoin de l'indice. Après dix, vous commencez à voir le même schéma dans votre propre code. Cette courbe est impossible à compresser en devinant. Pour un contexte plus approfondi sur les chaînes d'attaques derrière ces extraits, essayez le scénario d'apprentissage correspondant dans Mode apprentissage.