How I Found My First Bug

How I Found My First Bug

I still remember the exact moment.

It was past midnight. My room was dark except for the glow of Burp Suite on one monitor and a half-finished cup of tea on the other side of the desk. I'd been at this for weeks — reading writeups, watching hours of bug bounty walkthroughs, taking notes, practicing on labs. Trying to build the instinct.

And then, on what felt like a completely unremarkable evening, something came back that wasn't supposed to.

A Little Background: What Is BOLA?

Before I get into the story, let me explain what I was even looking for — because when I first heard the term Broken Object Level Authorization, I had no idea what it meant either.

Here's the simple version.

When you use a web application, you're constantly asking the server for things. "Show me my order." "Give me my profile." "Load my invoice." Behind the scenes, those requests usually include some kind of identifier — a number or a code that tells the server which object you want.

The question the server is supposed to ask is: does this user actually own this object?

BOLA — also called IDOR (Insecure Direct Object Reference) — happens when the server forgets to ask that question. It just fetches whatever ID you send. Change the ID to someone else's? You get someone else's data.

It sounds almost too simple. That's why it's so common.

It's been the number one API vulnerability category for years, and yet it keeps showing up — in startups, in enterprises, in platforms trusted by millions of users. Because in the rush to ship features, authorization checks get assumed, skipped, or just forgotten.

The Application

The platform I was testing was a multi-tenant SaaS product — the kind of system that serves multiple separate businesses under one roof. Think of it like a shared office building: everyone's inside the same structure, but each company has its own locked floor. They shouldn't be able to see each other's spaces.

This particular platform handled inventory. Warehouses. Stock levels. The kind of operational data that a business keeps close to its chest.

I'd signed up for a legitimate test account. Standard practice — you work within a scope you're authorized to test, with credentials you've legitimately obtained. I had my own little corner of the platform. Products I'd created. A warehouse assigned to my account.

I opened Burp Suite, started browsing the application normally, and watched the requests flow in.

The Request That Caught My Eye

After a few minutes of clicking around, I spotted an API call that looked interesting.

It was a POST request — the kind that sends data to the server rather than just asking for a page. The body contained two things: a list of product variant IDs, and a single warehouse location ID.

Something about that second parameter made me pause.

The product IDs made sense to include. Of course the server needs to know which products you're asking about. But the location ID felt different. It was just a number. A small, plain integer. And my first thought was: is the server actually checking whether this location belongs to me?

That's the question. That's always the question with BOLA. Not "can I access this endpoint?" but "is the server verifying I own what I'm asking for?"

The Test

I right-clicked the request in Burp and sent it to Repeater — the tool that lets you modify and resend requests manually.

First, I sent it as-is. It came back with my warehouse data. Expected. Everything looked normal.

Then I changed one thing.

I incremented the location ID by one. Kept everything else identical — same authentication token, same product IDs from my own account. Just changed that single integer.

I hit send.

The server thought about it for a fraction of a second.

Then it returned HTTP 200.

Not a 403 — Forbidden. Not a 401 — Unauthorized. Not an error of any kind.

200. Success.

And in the response body: inventory data. Real data. A warehouse name I didn't recognize. Stock quantities. An asset valuation in dollars. And a figure labeled as Moving Average Cost — a per-unit cost metric that businesses treat as a trade secret, because it reveals exactly what they paid their suppliers and what their margins look like.

All of it. From a warehouse that had nothing to do with my account.

I leaned back slowly and read the response again, just to make sure I wasn't misreading it.

I wasn't.

What I Was Looking At

Let me be specific about why this was serious — because "you can see someone else's data" doesn't quite capture the scale of it.

The warehouse location IDs were sequential integers. 1, 2, 3, 4, and so on. No randomness. No cryptographic tokens. Just incrementing numbers.

That meant there was no guessing required. Anyone with a valid account could write a loop — literally a few lines of code — and iterate through every location ID on the platform from 1 to however many existed.

Every warehouse. Every tenant. Every business that had ever signed up.

Their stock quantities. Their asset valuations. Their Moving Average Cost figures. Their warehouse locations and geographic footprint.

The kind of competitive intelligence that would take a market research firm months to compile, and cost tens of thousands of dollars — available to any authenticated user in an afternoon, silently, without triggering a single error or alert.

And the scariest part? There was no indication anything was wrong. No rate limiting tripped. No alarm fired. The server happily returned 200 OK every time, because as far as it was concerned, the request was perfectly valid.

When I dug into the logic of what the server was doing, the flaw became clear.

The API was checking the product variant IDs. It verified that those belonged to the authenticated tenant. That check existed, it worked, and it was the right instinct.

But the location ID? Trusted completely. Plugged directly into the database query without ever asking: does this location belong to this user?

It was a partial authorization check. Half the parameters were validated. The other half were taken at face value.

This is one of the most common patterns in BOLA vulnerabilities — not a total absence of authorization, but an incomplete one. The developer thought about the objects they were obviously fetching. They didn't think about every object in the request.

Writing the Bug Report

Once I'd confirmed the behavior and understood the scope, I stopped testing and started documenting.

A good bug report isn't just "I found something broken." It tells the program exactly what's wrong, why it matters, and how to reproduce it step by step. Here's roughly how I structured mine:

Title: Broken Object Level Authorization (BOLA) on inventory endpoint — cross-tenant warehouse data exposure via unvalidated locationId parameter

Severity: Critical

Summary: A one-paragraph plain-English explanation of the flaw — what parameter was missing an authorization check, what data was exposed, and what an attacker could do with it.

Steps to Reproduce: Numbered, precise, reproducible. I wrote it so that someone who had never seen the application before could follow the steps and land on the same result.

1. Authenticate to the platform and obtain a valid session token.
2. Navigate to the inventory section and intercept traffic in Burp Suite.
3. Identify the POST request to the inventory endpoint containing variantIds and locationId.
4. Send the request to Repeater. Note the response returns your own warehouse data.
5. Increment the locationId value by one and resend.
6. Observe the 200 OK response containing another tenant's warehouse name, stock quantities, asset valuation, and Moving Average Cost.

Expected Behavior: The server should return a 403 Forbidden when the supplied locationId does not belong to the authenticated tenant.

Actual Behavior: The server returns a 200 OK with full inventory data for the foreign warehouse.

Impact: I spent extra time here. I didn't just say "sensitive data is exposed." I was specific — Moving Average Cost reveals supplier pricing and margin strategy. Sequential integer IDs mean the entire platform can be enumerated. This is a regulatory concern under SOC 2 and data isolation SLAs. I explained it in business terms, not just technical ones.

Proof of Concept: I attached the Burp Repeater screenshots, annotated to show the parameter change and the resulting data difference.

I submitted it, marked it critical, and waited.

The response came back faster than I expected. Confirmed. Valid. Triaged as a critical severity finding.

That notification landed in my inbox at around 2am. I read it three times.

What This Bug Taught Me

Looking back, the thing that strikes me most is how simple the discovery was. I didn't use any special exploit. I didn't chain five vulnerabilities together. I changed one number in one field and asked the most basic possible question: will the server stop me?

It didn't.

If you're trying to find your first bug, here's what I'd take from this:

Read every parameter, not just the obvious one. When you intercept a request, look at everything being sent. For each value, ask yourself — is the server actually validating ownership of this, or is it just trusting whatever I send?

Sequential integers are a signal. When you see a plain number as an identifier, that's an invitation to ask whether authorization is being enforced. Randomized UUIDs are harder to enumerate. Small integers are not.

Think about multi-tenancy. Any platform that serves multiple users or organizations has to maintain data isolation between them. That isolation is enforced in code — and code can have gaps. Find the gaps.

Start with boring requests. The flashy attack surface gets scrutinized. The quiet API call that loads a dropdown or populates a table? Often not. The most impactful bug I've found was hiding in the least exciting request on the page.

You don't need a complicated setup. Burp Suite Community Edition is free. A test account is free. Curiosity is free. That's all I had.

The Bigger Picture

BOLA isn't a niche, exotic vulnerability. It's one of the most pervasive classes of security flaws in modern applications, and it shows up everywhere — from small startups to large enterprises — because the conditions that create it are built into how software gets written under deadline pressure.

Authorization is easy to forget when you're focused on making the feature work. It's easy to check one thing and assume the rest is fine. It's easy to trust a parameter that comes from your own frontend, forgetting that someone with a proxy tool can change anything.

Every platform serving multiple users has to ask, for every request: is this person allowed to see this specific thing? Not just "are they logged in." Not just "do they own something similar." This exact thing.

When that question doesn't get asked, someone like me — sitting in a dark room with a cup of tea — will eventually find the answer for them.

If you're just starting out in security research, your first bug is probably hiding in a request you've already seen. You just haven't changed the ID yet.

Happy hunting.

A note on disclosure: After submitting this report, I learned the vulnerability had already been found by the platform's internal penetration testing team. Two independent testers, same flaw, same window of time. If we both found it — how many others did too, and said nothing?

If this helped you think differently about authorization, drop a clap — it helps more hunters find this story. And if you've found a BOLA in the wild, I'd love to hear how in the comments. The pattern is always the same, but the context is always different.