3 IDOR Bugs That Paid $113,000 Combined — Here’s the 5-Minute Pattern Behind All of Them

30-Second Version:_ Three publicly disclosed IDOR reports — against Meta, GitLab, and Snapchat — paid $78,000, $20,000, and $15,000. A 2025 analysis of 250 disclosed IDOR reports on HackerOne found the same root cause behind nearly all of them: a single ID in a request that nobody checked belonged to the requester. This article breaks down all three, ranked, and the one five-minute test that would have caught every single one before it ever reached production._

$78,000.

That's what Meta paid out for a single authorization flaw disclosed just weeks ago. Not a zero-day. Not custom malware. A researcher named Roy found a gap in how Meta's backend support infrastructure checked who was allowed to see what — and walked away with one of the largest individual bounties reported this year.

IDOR bugs have this in common across almost every disclosed report: they're conceptually embarrassing and financially serious at the same time. A 2025 study analyzing 250 disclosed IDOR reports on HackerOne found these vulnerabilities have resulted in over $129,000 in confirmed payouts, with individual reports reaching $20,000, and 36.4% rated High or Critical severity. The "IDOR is always low severity" assumption is exactly what keeps producing headlines like this one.

Here are three of the biggest, ranked, and the pattern that connects every single one of them.

Case 1 — Meta, $78,000

Setup: A researcher testing Meta Horizon Managed Solutions, the enterprise platform businesses use to manage fleets of Meta Quest devices, found what looked at first like a narrow authorization issue in a single admin panel.

Twist: It wasn't narrow. The flaw traced back to a shared backend system powering Meta's customer support infrastructure more broadly — meaning the exposure extended well past the original panel where it was first spotted.

The punch: One authorization check, missing in one shared backend service, exposed customer support data across a surface far larger than the feature where anyone first noticed it.

Case 2 — GitLab, $20,000

Setup: GitLab's Machine Learning Model Registry assigned IDs to private ML models sequentially — 1, 2, 3, and so on — the same predictable pattern that's been a known anti-pattern in web security for over a decade.

Twist: Because the IDs were guessable and the endpoint never verified the requester actually had access to that specific model, anyone could enumerate through every private model on the platform, across every GitLab tier, simply by changing a number in a URL.

The punch: No exploit chain. No custom tooling. Just counting upward, against a company whose entire product is built for developers who should have known better.

Case 3 — Snapchat, $15,000

Setup: Snapchat's platform for monetized creator content included a deletion endpoint — a completely standard feature letting creators manage their own uploaded content.

Twist: The endpoint identified which content to delete using a content ID passed in the request, with no server-side check confirming that content actually belonged to the account making the request.

The punch: Any authenticated user could delete any other creator's monetized content on the platform, simply by knowing or guessing the right ID — turning a routine content-management feature into a fully weaponizable griefing tool.

The Pattern Behind All Three

Strip away the specific product, the specific company, and the specific ID format, and all three reports collapse into the exact same missing question:

Does this ID belong to the account making this request?

Does this ID belong to the account making this request?

Not "is the user authenticated." Not "does this ID exist." Specifically: does the resource this ID points to actually belong to, or was actually shared with, the identity attached to this request.

Meta's flaw sat in a shared backend never designed to ask that question at the right layer. GitLab's flaw sat in sequential IDs nobody gated behind ownership verification. Snapchat's flaw sat in a deletion endpoint that checked whether the content existed, but never whether it belonged to the requester.

The 5-Minute Test

Before shipping any endpoint that accepts an ID — a user ID, a model ID, a content ID, a document ID, anything — run this test:

1. Authenticate as User A
2. Perform the action normally, note the ID used
3. Authenticate as User B (a completely
   different, unrelated account)
4. Repeat the exact same request, but substitute
   User A's ID instead of anything belonging to User B
5. If the request succeeds, you have an IDOR

1. Authenticate as User A
2. Perform the action normally, note the ID used
3. Authenticate as User B (a completely
   different, unrelated account)
4. Repeat the exact same request, but substitute
   User A's ID instead of anything belonging to User B
5. If the request succeeds, you have an IDOR

Five minutes. Two test accounts. No tooling required beyond curl or Postman. This single test, run against the specific endpoints involved in all three cases above, would have caught every one of these vulnerabilities before a single dollar was ever paid out.

The pattern connecting $113,000 in combined disclosed bounties isn't sophistication. It's the absence of a five-minute test that nobody ran.