Web Application Bug Bounty Case Study: $25,000 Finding in an Airline Rewards API

The Target: A Loyalty API with Predictable Resource IDs

During a public bug bounty program, we focused on an airline's loyalty rewards API. The endpoint for retrieving account balance was: GET /api/v2/members/{memberId}/balance. The member ID was a sequential 8-digit integer.

Changing the memberId in the request to any other integer returned the balance of that account — no authorization check. The API verified that the caller was authenticated, but not that the caller was authorized to access that specific memberId.

BOLA: The Most Common API Security Failure

Broken Object Level Authorization (BOLA), known as IDOR in older nomenclature, tops the OWASP API Security Top 10 for a reason. It is the simplest vulnerability conceptually — you are accessing a resource that should not be yours — and among the most commonly missed because API development frameworks do not enforce object-level authorization automatically.

Impact Assessment

Beyond read access, we found the modification endpoints were equally vulnerable. A PUT request to /api/v2/members/{memberId}/balance with a modified memberId allowed us to credit points to our own account using a CSRF-style replay. The theoretical impact: unlimited miles for any attacker, and complete visibility into 47 million customer accounts.

Reporting and Timeline

Initial report: Day 0. Triage accepted: Day 3. Severity confirmed Critical: Day 11. Partial patch (read endpoints only): Day 45. Full remediation across all endpoints: Day 247. Bug bounty paid: $25,000 on Day 89 despite the extended fix timeline, reflecting the severity and quality of the report.

Remediation Pattern

The fix required adding a server-side check on every object-level API operation: does the authenticated user's identity match the owner of the resource being accessed? This check must happen in the application layer, not the API gateway, because the gateway does not understand business-level ownership semantics.