Introducing the Secure Code Review Challenge (Practice Real-World Reviews)

📢 I have some exciting news: I'm launching a new series called the Secure Code Review Challenge. Check out the video version of this story here

If you've been looking for resources to practice secure code review, you've probably found one or two of these online already. The problem, in my opinion, is that most of them use sample code that's just meant to train you to recognize dangerous patterns — things like SQL injection or IDOR. That's useful, but it's not what secure code review actually looks like in practice.

In reality, secure code review is a much bigger and more complex process. It includes going through an application, understanding how it works and its architecture, identifying the entry points, figuring out which vulnerabilities are actually relevant, checking where (and whether) they're mitigated in the code — and then, for anything you suspect is a real vulnerability, confirming it's exploitable and suggesting a fix that doesn't break functionality.

There just aren't good resources out there to practice that full process. So I built one.

Who This Is For

This series is aimed at AppSec engineers and developers who want to get better at reviewing code for security issues, as well as pentesters, bug bounty hunters, and security researchers who want more practice reading and reasoning about real application code.

What This Series Is

The Secure Code Review Challenge is a set of challenges you can work through to practice the entire secure code review process, not just pattern recognition. A few things make these different from what's already out there:

Full applications, not snippets. Every challenge is a realistic application with its own database, backend, and UI — you review it the way you'd review a real codebase, not an isolated function.

Vulnerabilities based on real-world issues. The bugs planted in each challenge are grounded in actual CVEs and vulnerability writeups, not invented for the exercise.

No multiple choice. There's no list of options to guess from — you identify the vulnerability yourself, the same way you would in a real review. That's what makes this a complete review exercise rather than a recognition quiz.

The full methodology, not just spotting the bug. Each challenge is meant to be worked through using the suggested methodology in the repo — more on that below.

The Methodology Behind the Challenges

Each challenge is meant to be worked through using the suggested methodology in the repo, which builds on the same two-category mental model I laid out in my threat-model-first methodology story: most security issues are either business-logic vulnerabilities (missing controls like authentication, authorization, or CSRF protection — things a scanner won't catch, because whether they're missing depends on the app's specific logic) or source-to-sink vulnerabilities (user-controlled input reaching a dangerous function without enough validation — the pattern behind SQL injection, XSS, SSRF, and similar bugs).

The suggested steps for working through each challenge:

• Understand the application's scope and architecture.
• Identify the entry points — web pages and backend endpoints/routes.
• Identify the dangerous sinks in the code and its dependencies (SQL queries, OS commands, HTML rendering, and so on).
• Threat-model using the two categories — business-logic and source-to-sink.
• For each threat, determine whether it's mitigated in the code — and how or where.
• Identify potential vulnerabilities and try to exploit them.
• For each exploitable vulnerability, suggest a fix.

That's exactly the process each challenge is designed to put into practice — not by handing you a snippet and asking "what's wrong with this," but by giving you a real application and asking you to go through the whole process yourself, the way you would on the job.

How It Works

The first challenge, 001-schooled, is already live on the GitHub repo, and this is going to be a biweekly series: every two weeks, I'll publish the solution to the current challenge along with a brand new one.

Each challenge comes with its own README covering how the application works, some details on the architecture, and how to run it locally — you'll be able to spin it up, interact with it as a user (register an account, log in, get a JWT token, and so on), and start working through it. Everything runs locally with throwaway secrets — these apps aren't meant to be deployed anywhere public.

The repo includes a SOLUTION_TEMPLATE.md you can copy into your own private notes and fill out for each challenge — covering architecture, relevant threats, mitigations, exploitability, and fixes. You're welcome to use your own approach instead, but it's there if you want a starting point.

One important note: don't post your findings, exploit, or fix in the repo's Issues or Discussions until the official solution is published — keep your notes private until then so you don't spoil it for other people still working through it. A public wiki of vulnerability write-ups (to reference while you work through challenges) is coming soon.

Try It

Head over to the repo, clone challenge 001, and give it a try. If you're looking for a way to actually practice secure code review — not just recognize a handful of vulnerability patterns — I think this is built for you.

I'll be sharing my own solution to the first challenge in a couple of weeks, both here and on the channel, along with the next challenge. Let me know if you give it a try, and feel free to leave any feedback in the comments. Stay tuned!