Concerned your API keys and other secrets are out in the open?
Free, no obligation API Leaks Assessment
Privacy settings
We use cookies and similar technologies that are necessary to run the website. Additional cookies are only used with your consent. You can consent to our use of cookies by clicking on Agree. For more information on which data is collected and how it is shared with our partners please read our privacy and cookie policy: Cookie policy, Privacy policy
We use cookies to access, analyse and store information such as the characteristics of your device as well as certain personal data (IP addresses, navigation usage, geolocation data or unique identifiers). The processing of your data serves various purposes: Analytics cookies allow us to analyse our performance to offer you a better online experience and evaluate the efficiency of our campaigns. Personalisation cookies give you access to a customised experience of our website with usage-based offers and support. Finally, Advertising cookies are placed by third-party companies processing your data to create audiences lists to deliver targeted ads on social media and the internet. You may freely give, refuse or withdraw your consent at any time using the link provided at the bottom of each page.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
API Security OWASP, Attacks

Excessive Data Exposure

Excessive Data Exposure


API3:Excessive Data Exposure

Threat agents/Attack vectorsSecurity WeaknessImpacts
The core of this vulnerability exists in the fact that an API should only return data to the user which is actually required. If we serve more data this could lead to an attack where a malicious actor could sniff the traffic from our API's by performing a MitM attack and abuse this data. We will go into some more examples later on in this article so it will be more clear.This vulnerability is so prevalent (place 3 in the top 10) because it's easy to miss. Automation is near useless here because robots can not tell what data should not be served to the user without telling them exactly how the application should work. This is bad because API's are often implemented in a generic way, returning all data and expecting the front-end to filter it out.When sensitive data is exposed as such, this could have a severe business impact depending on what data is being exposed but due to the nature of the sensitive data, it is almost always going to cause great impact by definition.
Learning Objectives

What is Excessive Data Exposure?

An API is only supposed to return the required data to the front-end clients but sometimes teams will make a mistake or take the easy route and implement APIs that return all data to the client. When these API's return too much data, we can speak of Excessive Data Exposure.

Example Attack Scenarios

A simple example we can give is an application which makes a call to grab the credit card details. The user does not see the CCV because it will be filtered out by the front-end client but the API still returns too much data.


GET /api/v1/cards?id=0
        "CVV": "677",
        "creditCard": "1234567901234",
        "id": 0,
        "user": "API",
        "validUntil": "1992"
Example of Excessive Data Exposure

As you can see here, we made the call to grab the credit card details and while the end user might not be able to see the CVV but since the API returns it, we are speaking of Excessive Data Expsoure.

Let's add another example to make things more clear. In this scenario we have a mobile application that makes a GET request to /api/articles/{articleId}/comments/{commentId} and gets metadata about the comment as well, including the author. However when someone is sniffing the data, they can also see PII data from the author.

GET /api/v1/comments?id=0
        "comment": "1234567901234",
        "id": 0,
        "user": "testUser",
        "user adress": "testlane, testing - 340043 testing in testland",
        "user email": ""
Example of Excessive Data Exposure 2

Preventive measures against Excessive Data Exposure

  • We should never rely on the client to filter out data
  • We should investigate all the responses coming from the back-end to see if they include sensitive data
  • When creating a new API endpoint, we should take in mind who the consumers of the data will be and exactly what data they need
  • There are certain methods such as to_json() and to_string() which will indiscriminately print out the whole object we pass onto and can produce undesirable effects. We should opt for only returning specific properties of an object and never the full object itself fed into a to_json() or to_string() function.
  • All PII data your application works with should be classified and re-indexed on a regular basis. Every API call that is new or existing should have their responses reviewed to check if they do not contain any PII data that is not required.
  • Scheme-based validation is when we validate a request or response against a predefined scheme. This can be used to add to the security repertoire and should be used to check all of the responses that leave the API. This will ensure no sensitive data will leave the API but it is very labour intensive to create those schemes.
Preventive measures against Excessive Data Exposure


The deceptive simple nature of this issue type makes it very easy to overlook and our automation is not very likely to pick this issue type up either so it's very easy to slip under the radar. To help you filter your data - API security solution. We have compiled the OWASP Top 10 2021 ranking based on statistical data. It's highly recommended that you judge all data leaving API's on their sensitive nature and what data it should send off to the front-end. Front-end filtering should be avoided if at all possible.

Watch the video:



Subscribe for the latest news