Excessive Data Exposure

Too much information is passed on from the API to the client, with the client bearing the responsibility of filtering what API resources and other information are displayed to the end-user.

As a result, an API may return sensitive information, which although is not displayed visually, still exists in the API. This is of particular concern with user data, because of the potential legal ramifications associated with the accidental leaking of sensitive information such as private information, financial information, and health-related one (violating regulations such as: GDPR, HIPPA, PCI-DSS). Although this common development practice provides flexibility during development, allowing all the data to be returned and, as the UI is being built, filter what is required. This practice produces a security risk because, even when sensitive data may be designed to be accessible only by authorized and authenticated users, an attacker can view all the data sent by the API at the endpoint by circumventing the client or otherwise analyzing the traffic to the client from the API (man-in-the-middle attacks).

As a result, the entirety of the data sent through the endpoint unintentionally becomes visible to the attacker, as it has been intercepted before reaching the client-side filter. Excessive data exposure can be an approach to develop APIs quickly, but this corner-cutting can lead to this common and impactful vulnerability.

Information disclosure, the elevation of privilege.

The issue can be found in the source code of the client.

OWASP recommends:

1. Avoiding excessive data exposure and not relying on the client to carry out the information filtering, instead opting for the filtering to occur at the API level before the information is sent to the client.
2. Ensuring that each client receives only the necessary information. This step should be carried out at the API design stage to ensure that once the API is deployed, a regular user’s client would only receive information that the client needs and no extra data, such as information only administrators should have.
3. Classifying any sensitive and personal information and reviewing how this information is used by the API to avoid sending it when it is not necessary as part of the functionality. For instance, does an API for hotel room bookings have to list every room occupant or just the number of empty rooms?

• Never rely on the client side to filter sensitive data.
• Review the responses from the API to make sure they contain only legitimate data.
• Backend engineers should always ask themselves, "who is the consumer of the data?" before exposing a new API endpoint.
• Avoid using generic methods such as to_json() and to_string(). Instead, cherry-pick specific properties you do want to return.
• Classify sensitive and personally identifiable information (PII) that your application stores and works with, reviewing all API calls returning such information to see if these responses pose a security issue.
• Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism, define and enforce data returned by all API methods, including errors.

• CWE-213
• CVSS: 3.1 base score: 7.5 (High)

• https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa3-excessive-data-exposure.md
• https://www.traceable.ai/owasp-api/excessive-data-exposure
• https://cwe.mitre.org/data/definitions/213.html