Excessive Data Exposure

What Is Excessive Data Exposure?

An endpoint serializes an entire stored record and trusts the client app to display only the safe fields. Callers read the raw response, not the rendered interface. You'll open a profile card showing a name and a city, capture the call behind it, and find email, phone, date of birth and home coordinates in the payload, then repeat it against a discovery feed for thousands of people. The fix is an explicit server-side allow-list projection. The patched endpoint still answers 200, just with fewer fields.

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.