Get a Demo

OWASP API Security Top 10 - Excessive Data Exposure

This week we look at the third item in the list of OWASP API security top 10 Excessive Data Exposure. Descriptions of other OWASP API top 10 can be accessed from the introductory blog available here.


APIs retrieve necessary data from back end systems when client applications make an API call. However, most of the backend systems were not designed to handover the exact data that the client requested. Rather, the API serves more data than what is needed by the client and then a filtering mechanism is used in the client app code to mask or discard unwanted data. If an attacker launches the underlying API and examines the response patterns, they are able to access the redundant data which could contain sensitive information. Besides returning excessive data records in response to a client request, an API may also expose certain references to the platform technologies used by the application. This allows hackers to look for vulnerabilities on such software and attack the system using that information.


Let us look at couple of real-world incidents where APIs exposed more data than necessary:


  • Facebook Marketplace Sale Item Location Disclosure


A security investigator reported that the Facebook Marketplace app was leaking accurate location information of a sale item that is advertised. The API request was revealing detailed location information, upto 6 decimal places in a JSON response. Revealing the seller’s exact location by looking at the advertisement may allow the user with malicious intent to launch social engineering attacks against the victim. Facebook has now fixed this issue by randomizing the seller’s location to a nearest generic location. 

Figure 1: Facebook Marketplace – Revealing Seller’s Location 


  • 3FUN Dating App Excessive data exposure


3FUN is a location-based mobile online dating application for Android and iOS and also one of most widely used dating mobile apps. As per the vulnerability, 3FUN app exposed the real time location of any dating-matched user along with their sensitive information such as date of birth, sexual preferences, and private pictures even if privacy option is set. Specifically, the API  /match_users was used to search for partners and when invoked by sending the current user’s location (longitude and latitude) information along with other search parameters such as age range, preference etc., the API responded with all the profile information of other matched users including location details and links to private pictures as well as highlighted earlier.


Figure 2: 3FUN App Vulnerable API Call


Though the mobile app was displaying only the necessary information as per privacy settings , the actual problem is that the data was not filtered at the server and relied on the app itself. Data obtained this way can be used to stalk users in near real-time, expose their private activities, or worse.


PlentyofFish, Tinder were some of many other dating apps whose APIs were also responding with more than what was needed.



Protection Mechanisms


Protection from excessive data exposure should start from the API design phase. First, among the API use cases, carefully choose the generalized payload which will cater to many situations with little variations. This will reduce the number of APIs but also increase the possibility of leaking information. Hence it is important to review each API use case and the response payload it carries for other than the required information. 


Developing and maintaining a detailed and valid API Specification that follows standards such as OpenAPI or RAML brings a lot of discipline to the API design process. If there is an API Specification document, implement an additional layer of security in the form of a policy which consumes this specification and monitors the data returned by all API methods, including errors to conform to the specification. 


In addition, It is not advisable to rely on the client side to filter data to show only relevant information. As we have seen in numerous examples above, filtering the data on the client side where no control can be exercised, can be easily bypassed. 


CloudVector Platform helps in following ways to reduce the threat of Excessive Data Exposure:


  • Follow these API best practices for strengthening API security at design phase.

  • Blueprinting the API Specification based on live traffic monitored from different applications running in production/staging environments. If API Specification is already available, you can compare with the one generated from blueprint and take appropriate actions on any deviations observed.

  • Policies can be defined on top of the API Specification or with respect to standalone APIs, the system will alert when specific parameters are seen/not seen in the API payload.

  • Policies can also be defined to look for anomalies in the response size or the number of records returned by an API.

  • Apart from providing a clear visibility into the API demographics, the CloudVector platform also labels sensitive data observed in the API payload. Such meta-label  identifiers help evaluate APIs which are particularly at risk of being affected by OWASP API #3 since APIs carrying sensitive data can be exploited for more damage than APIs which do not carry any such data.

Sekhar Chintaginjala is an experienced information security researcher who brings 15+ years of hands-on knowledge to the CloudVector team. He has proven expertise in the area of vulnerability research, security content development and leading teams for large global companies. At CloudVector, Sekhar is a member of the Security Research team and also leads efforts for new feature development that help protect from API abuses.