July 29, 2025
As a security engineer, I regularly work with real-world vulnerabilities in web, mobile, and API systems. Alongside that, I also design secure coding challenges that replicate these vulnerabilities in simplified, hands-on environments. These challenges are crafted to teach developers how security issues occur and how to write safer code through practical experience. It’s about going beyond bug fixing to encourage a mindset shift—from “does this work?” to “is this secure?”.
Over the years working in security engineering, I’ve come across the same types of issues repeatedly—access control misconfigurations, insecure input handling, broken logic in APIs. I’ve exploited them in live systems, written detailed reports, and recommended fixes.
But over time, I realized I wanted to do more than just find vulnerabilities. I wanted to help people understand them. Not through documentation or slides, but through experience. That’s why I started building secure coding challenges—an environment where developers can learn security concepts by doing, not just reading.
This post walks through how I approach challenge design, why realism matters, and how these challenges help change the way developers think about writing secure code.
As a security engineer, I’ve spent countless hours reviewing insecure code, exploiting flaws in web and mobile apps, and uncovering logic issues in APIs. But somewhere along the way, a thought kept returning: What if developers could discover these bugs before I did?
It’s easy to assume that security issues only happen when developers are careless. In reality, they often happen when people are trying to move fast, meet deadlines, or implement features without deep knowledge of how an attacker might think.
I’ve reviewed enough vulnerable code and exploited enough systems to see the patterns. But I’ve also worked with developers who, once they understood the risks, were quick to change how they approached problems. That shift in mindset—from reactive fixing to proactive thinking—is what these challenges aim to support.
Reading about the OWASP Top 10 is useful, but actually exploiting a broken access control flaw in a sandboxed challenge teaches the lesson in a way that sticks.
When I build a challenge, I start by thinking about issues I’ve seen during actual engagements. The idea is to replicate those flaws in a simplified environment that’s safe to break and learn from.
Some examples:
user_id parameter.These aren’t puzzles for the sake of puzzles. They’re grounded in real attack patterns, crafted to show how a small oversight can lead to serious consequences.
The goal of these challenges isn’t to stump people. They’re built to teach. Every aspect of the experience—from the vulnerable code or API behavior to the final explanation—is designed to guide the participant toward understanding what went wrong and how to prevent it.
A typical challenge includes:
By working through the problem directly, developers aren’t just learning how to exploit an issue—they’re learning how not to create one.
What I enjoy most about building these challenges is seeing how they help shift people’s thinking. I’ve seen developers go from treating security as something separate to seeing it as a natural part of design and development.
They start asking different questions:
Not just “Does this work”, But “What happens if someone misuses this?”
Not just “How fast can I build this?”, But “How can I build this safely?”
That shift is what makes the effort worth it.
Security isn’t just about finding bugs or writing secure code. It’s also about helping others build the awareness and confidence to do the same. While I continue to work on offensive and defensive security as part of my day job, building secure coding challenges is one way I contribute to improving the developer experience.
🎯 Whether you’re a developer trying to improve your security skills, or someone who wants to understand how attackers think, challenge-based learning is one of the most effective tools we have.
🧵 Thanks for reading! If you’re building secure coding training or looking to include such challenges in your org’s developer program, feel free to connect—I’m always happy to chat or collaborate.