Excessive Data Exposure is an API vulnerability in which an API returns more data than the client actually needs, exposing sensitive information that should have been filtered out. It commonly occurs when developers design APIs to return entire data objects and rely on the client application (such as a web page or mobile app) to display only the relevant fields and hide the rest. The problem is that the excess data is still transmitted in the API response – so even though the user interface may not show it, anyone inspecting the raw API traffic can see everything the API returned.
This is a classic API-specific risk that featured in the OWASP API Security Top 10 (later consolidated, along with mass assignment, into “Broken Object Property Level Authorization,” which focuses on missing or improper authorization at the level of individual object properties). The root cause is a failure to enforce proper filtering on the server: the API developer assumes the client is the only consumer and will responsibly limit what is displayed, forgetting that an attacker can bypass the client entirely and read the full response directly.
A typical example: an API endpoint returning a user’s public profile also includes sensitive fields like email address, phone number, date of birth, internal IDs, account status, or even password hashes and tokens in the same object. The front-end shows only the name and avatar, but the raw JSON response contains all of it, freely available to anyone who examines the API call.
The impact is unauthorized exposure of sensitive data – personally identifiable information, credentials, internal details – that can enable privacy violations, identity theft, further attacks, and regulatory breaches. Because the data is exposed through legitimate, correctly functioning endpoints, this vulnerability often goes unnoticed by tools that look for malformed requests or obvious exploits; the request and response are entirely valid, just over-sharing.
Preventing excessive data exposure requires enforcing data filtering on the server side, never relying on the client to hide sensitive fields. APIs should return only the specific data required for each use case, define and validate response schemas explicitly, apply property-level authorization so users receive only fields they are permitted to see, and review responses to ensure no sensitive information is inadvertently included. In short: the server, not the client, must be the arbiter of what data leaves the API.