Uber Eats BOLA (IDOR) Vulnerability | $2,000 Bounty | Technical Write-up

1. Introduction

In this technical write-up, I'll explain a BOLA (Broken Object Level Authorization) vulnerability originally discovered by 0xPrial on the Uber Eats Manager platform. I created this content to demonstrate and explain how the vulnerability worked, which allowed unauthorized access to sensitive analytics, revenue data, and sales details for any restaurant on the platform.

2. Technical Context: What is BOLA?

BOLA (formerly known as IDOR) is currently ranked #1 on the OWASP API Security Top 10 list. It is a logic flaw rather than a typical coding error.

• Logic Flaw: The server correctly verifies the user's identity (Authentication), but fails to verify if the authenticated user has the rights to access the specific resource or object requested (Authorization).
• The UUID Illusion: Developers often use UUID v4 (e.g., 0292a209-df33...) assuming their complexity makes them "unguessable" and therefore secure. In cybersecurity, this is known as Security by Obscurity, which is not a true security layer. Once a UUID is leaked through logs, referer headers, or other API endpoints, the system becomes vulnerable if ownership checks are missing.

3. Vulnerability Discovery & Methodology

While researching the Uber Eats Manager portal (restaurant.uber.com), I identified a specific endpoint used to fetch restaurant analytics.

Vulnerable Endpoint:

GET /v2/home/{locationUUIDs}/analytics/sales

The {locationUUIDs} parameter represented the unique identifier for a restaurant.

Proof of Concept (PoC) Steps:

1. Legitimate Session: I logged into the system using my own restaurant account (Attacker).
2. Target Identification: I obtained the UUID of a target restaurant (Victim).
3. Burp Suite Manipulation: Instead of manual changes, I used the Match and Replace feature in Burp Suite:

• Match: [My_Own_UUID]
• Replace: [Victim_UUID]

1. Execution: As I navigated through the analytics dashboard, Burp Suite automatically swapped my ID for the victim's ID in the background. The server, seeing a valid session but failing to perform an ownership check, responded with the victim's full financial and analytical data.

4. Impact Analysis

The exploitation of this BOLA vulnerability led to:

• Global Data Exposure: Unauthorized access to financial performance, daily/monthly sales, and order volumes of millions of restaurants.
• Business Intelligence Leak: Competitors could scrape proprietary performance data to gain an unfair market advantage.
• Scalability: A simple script could iterate through leaked UUIDs to "scrape" the entire platform's business data in seconds.

5. Remediation & Defense

To prevent BOLA, reliance on "secret" IDs is insufficient. A robust Ownership Verification layer is mandatory:

• Server-Side Validation: Every API request must verify the relationship between the requesting_user_id and the target_object_id within the database.
• Centralized Authorization: Implement a centralized authorization middleware to ensure consistent checks across all API endpoints.

6. Conclusion

Uber evaluated this finding as a high-severity issue and awarded a $2,000 bounty. This case reminds us that even the most complex systems can be compromised by simple logic flaws when authorization is overlooked.

Researcher: NullSecurityX

Video PoC:

Disclaimer: This research was conducted and reported responsibly under Uber's Bug Bounty program.

Join YouTube Channel: https://www.youtube.com/channel/UCTeWgz2WPpYgiPtu8zEY91g/join

Follow us for more:

YouTube: https://www.youtube.com/@NullSecurityX

Medium: https://nullsecurityx.medium.com/

Twitter (X): https://x.com/NullSecurityX

Instagram: https://instagram.com/NullSecurityX

Facebook: https://www.facebook.com/nullsecurityx/