The API returns sensitive data to the client by design. This data is usually filtered on the client side before being presented to the user. An attacker can easily sniff the traffic and see the sensitive data.
Understanding Excessive Data Exposure Bug
When an API endpoint returns more data than is required or meant for the user, this is known as an Excessive Data Exposure problem. This usually occurs when the API answer contains sensitive or unnecessary information that the requester shouldn’t be able to access.
As an illustration, suppose you are requesting information on an author via an API call. The API returns sensitive information like the author’s phone number, email address, and other private information, even though it should only return basic information like the author’s name and biography. The system is exposing more data than is necessary for the particular operation in this clear instance of excessive data exposure.
Example Attack Scenarios
Scenario #1
The mobile team uses the /api/articles/{articleId}/comments/{commentId} endpoint in the articles view to render comments metadata. Sniffing the mobile application traffic, an attacker finds out that other sensitive data related to comment’s author is also returned. The endpoint implementation uses a generic toJSON() method on the User model, which contains PII, to serialize the object.
Exploiting Excessive Data Exposure Bug Using crAPI
So, in order to exploit this specific vulnerability we will be using the crAPI move to the communities tab
To exploit excessive data exposure vulnerabilities, capture the HTTP history in Burp Suite to monitor the request and response interactions related to /community/apiv2/community/posts, and analyze the data that might be exposed inappropriately.
We notice a problem with the API request and response when we try to access the Communities page. In a typical situation, the API should simply return the most basic information when accessing the community content, like the author’s details and the content of the comment. But in this instance, the API answer exposes private information that shouldn’t be available, like the author’s email address, vehicle ID (basically the VIN number), and ID.
The API is unintentionally returning significantly more data than is required for the request, which is an obvious sign of an Excessive Data Exposure problem. Such a response should never reveal sensitive information, such as the email address or VIN number, as it may be used maliciously.
Response
{"id":"8YG2mv35HKqsQPGw5emNzk","title":"the stew","content":"agbadalasiminue","author":{"nickname":"fisway","email":"fishstew@email.com","vehicleid":"1fa3df1e-5625-471f-b47b-9ca8d66b43d4","profile_pic_url":"","created_at":"2025-05-27T21:36:01.255Z"},"comments":[],"authorid":2326,"CreatedAt":"2025-05-27T21:36:01.255Z"},Exploiting Excessive Data Exposure and Chaining It with BOLA Vulnerabilities
Leveraging the Refresh Feature to Trigger Access to Leaked Data
A car will be assigned to you automatically after you register on the CRAPI login page. You’ll see a Refresh button function as you go down. Analyzing and mapping the functionality of this feature into the program is our current responsibility.
Analyzing the Requests and Responses Triggered by the Refresh Feature
When we click the Refresh button, the API call made is GET /identity/apiv2/vehicle/<vehicle_id>/location HTTP/1.1. This corresponds to our VIN number since we are already logged in.
Upon checking the response of this request, we see that it returns our car ID and the vehicle location, which includes the ID, longitude, and latitude, along with our username.
Finding Anyone’s Location
The VIN number, which is effectively the car ID, was among the sensitive data that was leaked via the API in the previous assault, which took use of the Communities page’s Excessive Data Exposure vulnerability (endpoint: /community/apiv2/community/posts).
We will now forward this request to the Repeater tab of Burp Suite. We’ll change our VIN to the one we discovered on the Communities tab and adjust the parameters accordingly. This is an illustration of a vulnerability known as Broken Object Level Authorization, or BOLA. We might be able to find out where someone’s car is by tampering with the VIN, which could reveal private information.
And voila!!, the location details have been correctly retrieved. To achieve our objective, we essentially chained two vulnerabilities: we first used the Excessive Data Exposure flaw to obtain sensitive data (the VIN), and we then used a BOLA (Broken Object Level Authorization) weakness to further attack that vulnerability. This made it possible for us to find out where someone’s car was.
Real-time threat feeds from TOR, Telegram, & underground forums to detect silent breaches and impersonation risks. If your data is exposed, we’ll alert you with a clear report—what was leaked, why it matters, and what to do next.
