Excessive Data Exposure

What Is Excessive Data Exposure?

Excessive data exposure (OWASP API3:2019) is a data-leakage failure where an endpoint serializes an entire stored object and returns it in full, relying on the client application to display only the fields it needs. The screen looks harmless because the app renders a handful of safe fields, but the raw API response carries everything, so anyone who reads the response with an API client, a proxy, or the browser's network tab gets the private fields the interface quietly dropped. It is distinct from broken object level authorization, where the flaw is reaching another user's object by changing an identifier, and from broken function level authorization, where a low-privilege caller invokes a function they are not allowed to; here the caller is fully allowed to view the resource, and the bug is how many fields come back. This exercise puts you on both sides. As Bob, an ordinary member of Trailkin, a social running app, you open a target's public profile card, which shows only a name, city, and mileage, then open the browser's network tools and reload the page to capture the call the app itself makes. The captured response carries the whole record: email, phone, date of birth, and home coordinates precise to five decimals. You repeat it against the runners-near-you discovery feed and pull the same full record for thousands of people at once, a bulk directory of identities and home addresses with no break-in. As Alice, the backend engineer who owns the profile service, you open the router after a monitoring alert, see the serializer returning the whole athlete object and trusting the client to filter it, and ship the fix: an explicit allow-list projection built on the server that returns only the public fields, so the same request still returns 200 but the private fields never leave the server. The exercise closes with quiz questions on why the client is not a filter and why the fix is a smaller response rather than a 403, and its takeaways cover how a shared serializer spreads one leak across every route that uses it.

What You'll Learn in Excessive Data Exposure

• Recognize excessive data exposure: an endpoint returns more fields than the client needs because it serializes the whole object and relies on the client to filter, so the raw response leaks sensitive fields the screen never shows
• Understand that the client is not a security boundary: callers read the raw response, not the rendered UI, so any field in the payload is exposed regardless of what the app displays
• Distinguish it from broken object level authorization (reaching another user's object by id) and broken function level authorization (invoking a function above your role); here the caller is allowed to read the resource and the flaw is the field set returned
• Apply the fix: build responses from an explicit server-side allow-list or projection of public fields, never serialize a stored record wholesale, and trim shared serializers once to close every route that uses them
• Recognize that over-exposure is not an access-control bug: the fixed endpoint still answers with 200, it just returns fewer fields, so blocking the request would wrongly break a public feature
• Audit every endpoint that serializes a full model, especially list and discovery feeds where one over-sharing serializer becomes a bulk data export

Excessive Data Exposure — Training Steps

1. A public runner page

   Today Bob is targeting Trailkin, a social running app, to harvest personal data on its members at scale. He signed up as an ordinary member with a throwaway identity. Trailkin profiles are public by design: anyone can look up any runner. Bob opens a target's page, which shows the runner's public card and a feed of other runners nearby.

2. Only the safe fields, on screen

   The profile card is deliberately sparse. It is what everyone is meant to see, and it shows nothing an attacker could use to find or impersonate this person.

3. Runners near you

   Below the card, the same page shows Trailkin's discovery feed: other members running nearby. Like the profile, every card here shows only public details.

4. Watch the requests

   The card and the feed were each drawn from data the app fetched over the API. Bob opens the browser network tools and reloads the page once, capturing both of the calls the app makes to build it.

5. Two calls, and everything the card hid

   The network tools captured the reload. Both calls the page made are sitting in the request list, and Bob opens the response to the first one, the profile call.

6. Open the nearby call

   One profile is one victim. The feed's call is right there in the list. Bob clicks it to read what the runners-near-you request returned.

7. The leak, at scale

   The nearby response is the same leak, multiplied across the whole feed.

8. Knowledge check

   You just watched a plain member account read private details the app never displays. Lock in why.

9. The alert lands

   You own Trailkin's athlete profile service. Overnight, monitoring flagged a single member account pulling full records for thousands of users through the public profile and nearby endpoints. Security has emailed you the details.

10. Open the profile router

    Open the athlete router and look at how it turns a stored record into a response.