Excessive data exposure is a vulnerability hiding in plain sight: the app shows a clean, filtered screen, while the API response behind it contains far more than the user ever sees, extra fields, internal identifiers, other users' details, sometimes data that should never leave the server. The app filters for display, but an attacker reading the raw API response gets everything. It is a server-side design flaw that the polished UI conceals, which is exactly why it persists. Here is what excessive data exposure is, why the app's UI does not protect against it, and how to prevent it.
Short answer
Excessive data exposure is when an API returns more data than the client needs, relying on the app to filter what it displays, so an attacker reading the raw API response sees fields the UI never shows, such as internal identifiers, other users' details, or sensitive attributes. Per OWASP's API security guidance, the fix is server-side: return only the fields each client actually needs, rather than serializing whole objects and trusting the app to hide the rest. The app's filtered display does not protect the data, because the response is visible to anyone inspecting the traffic. Design API responses to expose the minimum, and never depend on the client to conceal data it received.
What you should know
- The API returns more than the UI shows: extra fields ride along in the response.
- The app filters for display only: which does not protect the data.
- Raw responses are visible: anyone can inspect the app's traffic.
- It is a server-side design flaw: fix it by returning only needed fields.
- Do not trust the client to hide data: exclude it on the server.
What is excessive data exposure?
It is an API handing the client more data than it should, and leaving the filtering to the app. A common pattern is an endpoint that serializes an entire object, a user, an order, a record, and returns all of its fields, when the screen only needs a few. The app picks out what it displays, so the user sees a tidy view, but the full object, including fields meant to stay internal, traveled to the device in the response. An attacker who inspects the API traffic, which is straightforward, sees all of it: email addresses, roles, internal IDs, flags, sometimes sensitive attributes that should never have been serialized. The vulnerability is not that the data is shown, it is that it is sent, because once it reaches the client it is exposed regardless of whether the UI renders it.
Why doesn't the app's UI protect the data?
Because the data is exposed the moment it is sent, not when it is displayed. The table makes the gap concrete.
| Assumption | Reality |
|---|---|
| The app only shows needed fields | The full response, with extra fields, reached the device |
| Hidden fields are safe | They are in the response and readable via a proxy |
| The UI is the boundary | The API response is the boundary, and it leaked |
| Filtering on the client protects data | The client received the data before filtering |
The core misunderstanding is treating the app's display as the security boundary. The app might render only a name and avatar, but the request it made returned the whole user object, and an attacker inspecting that response, with ordinary tools, reads everything it contained. Client-side filtering is presentation, not protection, so a response that over-returns data is exposed no matter how selectively the app shows it.
How do you prevent it?
Return only the fields each client needs, decided on the server. Design your API responses to include the minimum fields required for the use case, rather than serializing whole objects and returning everything, which means explicitly choosing which properties to expose per endpoint, often through a response model or data transfer object that contains only the intended fields. Never rely on the client to hide data it received; the server must exclude sensitive or unnecessary fields before sending. Pay attention to nested and related objects, which can drag along more than intended, and to fields like internal identifiers, roles, and flags that have no reason to reach the client. Combine this with object-level authorization so the client only gets objects it is allowed to see, and property-level care so it only gets the fields it should. The principle is to send the minimum, since anything you send is exposed.
What to watch out for
The first trap is serializing whole objects and trusting the app to filter, which exposes every field in the response; return only what is needed. The second is nested or related objects that include more than intended; check what your serialization actually emits. The third is treating the UI as the boundary, when the API response is where the data is exposed. Excessive data exposure is a server-side flaw, so it is fixed and tested on your backend, but a pre-submission scan such as PTKD.com (https://ptkd.com) reads your app against OWASP MASVS and surfaces the API endpoints your app calls, a useful inventory of the responses to review for over-exposure. The field-level design lives on your server.
What to take away
- Excessive data exposure is an API returning more data than the client needs and relying on the app to filter it, so the response leaks fields the UI never shows.
- The app's filtered display does not protect the data, because the full response reached the device and is readable by anyone inspecting the traffic.
- Fix it server-side by returning only the fields each client needs, using response models rather than serializing whole objects, and never trust the client to hide data.
- Use a pre-submission scan such as PTKD.com to inventory the API endpoints your app calls, then review their responses for over-exposure on the server.
