Looking forward to generic implementations, developers tend to expose all object properties without considering their sensitivity, relying on clients to perform the data filtering before displaying it to the user.
- OWASP API Security Top 10 2019 Report
This security vulnerability is simple in its functioning – 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 GDPR.
The simple answer is that it provides flexibility during development, allowing all the data to be returned, and as the UI is being built, filter what is required. This is 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.
The first and foremost recommendation by OWASP to avoid excessive data exposure is to not rely on the client to carry out the information filtering, instead opting for the filtering to occur at the API level, before the information being sent to the client. OWASP also suggests ensuring that each client receives only the information that is necessary. 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 that only administrators should have. Finally, they recommend 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?
Excessive data exposure can be an approach to quickly develop APIs, but this corner-cutting can lead to this common and impactful vulnerability.