I've always had an aversion for authority. Ever since I was a kid, I remember always trying to find a way around the rules. Tell me I can't do something, and suddenly it becomes a puzzle I need to solve, a challenge to overcome.
The Origin Story
In elementary and middle school, we got these HP school-issued laptops with Windows 7/8 installed on them that were extremely restricted as to what we could do with them (probably for good reason). But I hated it. I resented the fact that I couldn't watch YouTube videos or play games on them, but I think more importantly that I didn't have full control over them.
I would spend hours researching how to exploit the system. I vividly remember Windows 7 having this neat trick where you could boot into debug mode, open an informational text file, and through the options you can navigate the file system with full admin privileges because you were running in a pseudo-elevated context, replace the accessibility button with cmd, and on the login page gain full root access over the system.
By seventh grade, I had League of Legends running on my school laptop. I don't think the IT department ever figured out how I did it (although I did get lunch detention for it... but that's another story).
The $35 Limit
Fast forward to my current job. Every Monday, we got free lunch. The company placed a group order through DoorDash and everyone picked what they wanted. Although there were no limits, nobody abused the system.
Then new executive assistants came in and slapped a $35 limit on the lunch order.
I was never spending over $35 anyway. But the limit itself pissed me off. It was more a message of distrust than a limitation.
So I started getting two lunches every Monday. My first move was simple. The company always offered two restaurant options each Monday. Most people picked one and ordered about $35 worth of food. But since the two options were separate orders with separate allowances, I just ordered from both (I usually saved the other lunch for Tuesday).
The New System
Then they switched to a new platform called 'Sharebite'. It's like a corporate SaaS bullshit that built an abstraction layer on top of Uber Eats.
I was pissed off when I saw that the allowance was reduced to $25. In New York City, that's about the price of a sandwich after tax. This is something maybe Amazon would do, not a Series A startup... And again, it's not really about the money but more the message.
The Exploit
While I was ordering my lunch on Saturday, I looked for ways to get past the limit. I tried ordering from both options but it didn't work as the system was designed to track allowances across the group orders. But as I grew annoyed, I remembered that the night before, I had a conversation with one of my interns about race conditions. We were building a feature to store chat sessions for an AI assistant and wanted to use a “pending” status flag to prevent duplicate processing. His logic was if a session is already pending, a new request sees the flag and skips re-triggering it.
I told him that although it would work, I did want to note the fact that there is a race condition there. If two requests come in fast enough, they can both read the state before either one writes the “pending” flag. Both see “no session exists,” and both trigger a new run (it's textbook).
And that was when I had the lightbulb moment. I found out that the shopping cart isn't shared across devices. So if I open the app on my phone and the website on my computer at the same time, then each one would independently check the allowance when I place an order. That means I can create a situation where both requests read the allowance at the same time and both pass validation.
So I queued up a $19 order on my phone and a $20 order on my computer. Both within the $25 allowance individually. Then I clicked “Place Order” on both at the exact same time.
Both requests hit the server nearly simultaneously. Each one reads the database: “$25 allowance available.” Each one does the math—$25 minus my order, still positive, all good. Each one gets confirmed. Neither sees the other's deduction because the deduction hasn't been written yet when the other reads.
Both orders went through. $39 spent on a $25 allowance. Two lunches, no extra charge. And since the system supports multiple orders (just that user has to pay out of pocket for anything above the allowance), it worked like a charm.
Why This Works (Technically)
This is a textbook TOCTOU (time-of-check to time-of-use) race condition. The system checks the allowance and deducts from it as two separate operations without holding a lock. In the gap between check and deduction, another transaction can slip in with stale data.
The fix is straightforward: use a mutex or database-level row lock so that the check-and-deduct happens atomically. It's the same reason two people can't buy the last concert ticket—the system acquires a lock on the seat row, processes one transaction, then releases it for the next.
The thing is, if you come from a traditional computer science background, race conditions are drilled into you. Mutexes and atomic operations—it's second nature. But if you learned to code by vibing your way through it, by asking an AI to generate your backend, you probably never think about concurrency at all. The happy path works. The tests pass. And then someone like me comes along with two devices and an axe to grind.
I knew the moment I saw that platform that it would have this bug. A well-engineered system would use row-level locks or optimistic concurrency control. This one clearly didn't.
The Moral of the Story
I fixed a critical security vulnerability and brought our core api back to life twice in the last week. I think I deserve at least two lunches.