Practice Mode
Practice Mode presents code review challenges where you identify vulnerable code and select the correct fix. Available across 200+ topics covering the OWASP Top 10 (Web), OWASP API Top 10, OWASP Mobile Top 10, and OWASP Client-Side Top 10 — in multiple languages.
How It Works
Each challenge follows a two-phase system designed to test both your vulnerability detection and remediation skills:
Phase 1 — Find the Vulnerability
Read through a code snippet and identify which block contains the security vulnerability. Click the correct block among several highlighted options to advance.
Phase 2 — Select the Fix
Once you identify the vulnerability, choose the correct fix from multiple options. Each option looks plausible, but only one properly addresses the security issue.
Challenge Interface
Here's what a typical code review challenge looks like:
SQL Injection in user lookup
backend / python / web
A user-detail endpoint takes the id from the query string and uses it to fetch the matching row. One of the candidate blocks below trusts that value when it should not.
Choosing Your Language
Each topic has challenges in multiple programming languages. Your stack preference determines which language is shown by default — backend developers see Python, Java, or Go challenges, while frontend developers see React, Vue, or Angular.
You can switch languages at any time using the language selector. Your preference is saved so you always see challenges in your preferred stack first.
Using Hints
Each phase has its own hint button. Using a hint halves the score you earn for that phase, with a floor of 10 XP — so a clean first-attempt phase worth 100 XP becomes 50 XP if you used the hint, and a second-attempt phase worth 60 XP becomes 30 XP. Hints provide targeted guidance without giving away the answer — they point you in the right direction while still requiring you to think critically.
Hints are optional. They are especially helpful when you encounter an unfamiliar vulnerability type for the first time.
Scoring & XP
Each phase is scored independently. A correct answer on your first attempt earns the full phase XP; repeated wrong attempts and hint usage both reduce it.
| Phase outcome | Without hint | With hint |
|---|---|---|
| Correct on 1st attempt | 100 XP | 50 XP |
| Correct on 2nd attempt | 60 XP | 30 XP |
| Correct on 3rd attempt or later | 30 XP | 15 XP |
| Maximum per challenge (both phases first try, no hints) | 200 XP | |
The hint reduction is a 50% cut with a floor of 10 XP, so even a 3rd-attempt phase with a hint still earns at least 10 XP. The two phases run independently — a hint or wrong attempt in Phase 1 does not affect Phase 2.
What happens when you guess wrong
The first wrong attempt in either phase prompts you to retry on the same code. After the second wrong attempt in Phase 1, a short story dialog appears explaining the real-world consequences of the vulnerability you missed before letting you try again. There is no attempt cap — you can keep retrying, but each additional attempt past the third caps the phase at 30 XP.
Challenge Completion
After completing both phases, you see a score breakdown:
Reading the Phase 1 to Phase 2 Flow
The two-phase structure exists because vulnerability detection and remediation are different skills. Phase 1 trains your eye: given a complete function or method, which line is the dangerous one. You are not asked to write code; you are asked to read it the way a reviewer would. The vulnerable line is rarely the most syntactically interesting one. It is usually a quiet line that does something a developer would write without thinking, like concatenating a request parameter into a string that will later be parsed.
Phase 2 trains your judgement. Once you know where the problem is, the platform shows you several plausible fixes. Most of them compile, run, and look reasonable. Only one fully closes the vulnerability. Some options patch the obvious symptom while leaving the underlying primitive intact. Some options over-correct and break the function. The goal of Phase 2 is to make you reason about why a fix works, not just whether it looks safer than the original. Treat the wrong answers as a study guide: each one is a real mistake real developers make in real pull requests.
Why Guessing Wrecks the Learning Curve
The hint system halves the XP for a phase (with a floor of 10 XP), which sounds like a penalty but is structured as a trade. The trade is meaningful guidance for a lower score. Guessing without a hint costs you the same XP and teaches you nothing, because the feedback loop is too coarse to learn from. If you find yourself reading the snippet for less than thirty seconds before clicking, you are almost certainly guessing. Slow down, read the snippet twice, hypothesize where the trust boundary is, then click.
The right rhythm for a new vulnerability class is to read carefully, use the hint when you are stuck, and accept the score reduction as the cost of learning. After three or four challenges in the same class, you stop needing the hint. After ten, you start seeing the same pattern in your own code. That curve is impossible to compress by guessing. For deeper context on the attack chains behind these snippets, try the matching Learn scenario in Learn Mode.