In the world of application security, threats often evolve faster than defenses. But when OWASP announced a brand-new category for its 2025 Top 10, “Mishandling of Exceptional Conditions,” our guest, Vijay Raina, didn’t just take note—he took action. In a single weekend, he built a static analysis scanner to hunt for this specific class of vulnerability and immediately found critical authentication bypasses in production code. A specialist in enterprise SaaS technology and automated security tooling, Vijay joins us to share the story of his 48-hour build.
We’ll explore the thought process behind his rapid tool development, the technical nuances that separate effective scanners from noisy ones, and the surprising, real-world vulnerabilities he uncovered. We’ll also discuss how to shift team culture to prevent these issues and the practical steps developers can take to secure their own exception handling.
Your article kicks off with a flurry of activity—a new OWASP category drops on a Friday night, and by Sunday, you have a working scanner. What was it about “Mishandling of Exceptional Conditions,” and specifically the fail-open pattern, that triggered such an immediate and focused response? Walk us through your mindset during that initial research phase.
It was one of those moments where a formal announcement gives a name to something you’ve intuitively known was a problem for years. When I saw the new A10 category and read the line about applications returning “truthy values” during exceptions, a very specific and dangerous code pattern immediately flashed in my mind: return True inside an except block. I’ve seen it countless times during code reviews. It’s often written with good intentions—to keep an application from crashing when a dependent service like a database or an API hiccups. But in a security context, it’s a disaster waiting to happen. That night, I knew this wasn’t just a theoretical risk. I was certain this exact flaw was sitting in production systems, so the research phase was less about discovery and more about confirmation. I immediately mapped it to CWE-636, and the urge to build a tool to prove it was overwhelming. It felt less like a choice and more like a necessity.
You make a strong case for using Abstract Syntax Tree (AST) parsing over regular expressions. Using that example of the commented-out return True, could you break down exactly how AST avoids that kind of false positive and what practical trade-offs you had to accept when adding regex-based support for other languages?
Absolutely. This is the core of why this kind of scanner can be either incredibly useful or just another source of noise. A regex-based tool is essentially a text-finder. It would see the characters return True inside a try/except block and sound the alarm, regardless of context. It wouldn’t know that a # symbol in Python means the entire line is a comment and not executable code. That’s a classic false positive that wastes a developer’s time. AST parsing, on the other hand, doesn’t just read the code; it understands its grammatical structure. The ast module in Python transforms the code into a tree of nodes representing the program’s logic. My tool walks that tree, finds a Try node, inspects its exception handlers, and only then looks for a Return node whose value is True. It knows the comment isn’t part of the executable structure, so it’s simply ignored. The trade-off came when I wanted to add support for JavaScript, Java, and Go. Building a full AST parser for each language in a weekend wasn’t feasible. So, I accepted a compromise: I wrote regex patterns for them. I knew they wouldn’t be as accurate, but they were good enough to catch the most blatant and common cases, which was a pragmatic first step.
The 18-month-old authentication bypass is a chilling discovery. Beyond the technical flaw itself, what does a finding like that reveal about the half-life of “temporary” fixes and the challenges of organizational memory in software development?
That discovery was genuinely humbling and, frankly, a bit scary. It’s a perfect illustration of how the road to a security breach is paved with good intentions. The code had a comment right there: “for now.” Someone, 18 months ago, faced a deadline, made a pragmatic choice to prevent a total failure if the key service went down, and fully intended to come back and fix it. But then the next feature came along, and the one after that. People switch teams, priorities shift, and that “temporary” workaround becomes a permanent, forgotten vulnerability. It reveals that our systems for tracking technical debt are often failing us. A Jira ticket can get lost in a backlog of thousands, but a comment in the code is an even more passive, invisible form of debt. During our impact analysis, we determined that a 15-minute outage of that key service a few months prior could have allowed unlimited unauthorized transactions. They got lucky. That finding taught me that a “temporary fix” in a security-critical path is one of the most dangerous patterns in software engineering.
You put a significant amount of effort into features like visual HTML reports and CI/CD integration with a hard failure flag. Why do you believe these presentation and automation features are just as vital as the core detection logic?
Because a security tool that isn’t used is worthless. Early in my career, I spent weeks on a detailed security analysis, compiled a 50-page PDF report of findings, and sent it to a development team. The response I got back was a simple “looks good, thanks!” Nothing got fixed. That’s when I learned that the best detection logic in the world doesn’t matter if you can’t get people’s attention and make the findings actionable. A color-coded dashboard with big red boxes showing “Critical” next to a file name gets a completely different reaction. It’s immediate, it’s visual, and it prompts questions. Integrating the scanner directly into the CI/CD pipeline with a --fail-on critical flag takes it a step further. It changes the dynamic from a suggestion to a requirement. The pull request is blocked. It can’t be merged. This approach removes the “I’ll fix it later” excuse from the equation entirely and transforms security from an advisory role to an automated, unavoidable part of the development process.
You noted that this isn’t just a junior developer mistake; you found these patterns in code written by very senior engineers, suggesting it’s an issue of visibility. How can engineering teams adapt their code review practices to better scrutinize exception handlers, and what’s a practical first step for testing these difficult-to-mock failure scenarios?
That was one of the most surprising lessons. It proves this isn’t about a lack of skill but a lack of focus. We’re conditioned to review the “happy path” logic with extreme care, but the except block is often an afterthought, written quickly to handle a crash during debugging. To change this, teams need to make a cultural shift. During code reviews, an exception handler in an authentication or authorization function should be treated with the same level of suspicion as a function that executes raw SQL. Ask the question: “What happens when this code actually runs?” Don’t just assume it won’t. As for testing, I know it’s hard. Mocking a database timeout or a complete network partition isn’t trivial. A practical first step is to not try to boil the ocean. Pick your single most critical security function—probably user authentication—and invest the time to write one chaos-style test for it. Use a library or framework to simulate the authentication service becoming completely unreachable and assert that your function correctly denies access. Getting that one test working builds the muscle and the framework to expand that practice to other areas.
Let’s talk about the fix. You recommend a specific “fail closed” pattern. Using the silent audit log failure as an example, could you walk us through how applying your recommended fix changes not just the code, but the entire mindset around error handling as a security function?
The silent audit log failure is such a subtle but potent example. The original code was written with the mindset of “don’t let a logging failure break an important admin action.” It prioritized application availability over security visibility. Applying the “fail closed” pattern completely inverts this. The fix involves changing the except block fundamentally. Instead of catching the exception, logging a warning, and then returning True to let the action proceed, the new code does the opposite. First, you catch a specific exception, not a generic one. Inside the handler, you log the failure as a critical error, not a warning. You increment a metric that can be tied to an alerting system. And most importantly, you re-raise the exception or return False or an error object. The admin action is blocked. This shifts the mindset from error recovery to defending a boundary. The failure is now loud, not silent. It forces an operator to investigate why the audit database is down. It correctly treats the inability to create an audit trail as a security failure just as critical as the failure of the primary action itself. It redefines the exception handler as a security gate, not a convenience path.
Do you have any advice for our readers?
Go back to your codebase right now and find the most critical security function you own—authentication, permission checking, payment processing. Find every try/except block in that code. Look at what happens in the except handler and ask yourself one simple question: “If a network glitch or a service outage makes this exception fire in production at 3 AM, am I granting access or am I denying it?” Your answer to that question might surprise you. Treat every exception path as a potential security decision, because in a world of distributed systems, failure is not a possibility; it’s a certainty. Your exception handlers will run, and you need to be sure they’ll make the secure choice when they do.
