Your API returns more than your UI shows: how to check

This one is not carelessness, it is the path of least resistance, and it is worth understanding because it tells you which endpoints to check first.

You ask for a profile page. The agent needs the user’s row, so it writes the shortest query that returns a row — select("*"), or findUnique with no field selection, or SELECT * FROM users WHERE id = $1. Then it sends that object as JSON and renders two fields from it in the component.

The page looks exactly right. Every test passes. The feature is done by any measure the agent can see, and no part of the loop raises an objection, because from the outside a response with two useful fields and a response with nineteen are indistinguishable.

This takes about five minutes per screen and needs no tooling beyond the browser you already have open. The discipline is to read the response body instead of the rendered page.

1. 01Open your app and sign in as a normal account. Open developer tools, go to the Network tab, and filter to Fetch/XHR.
2. 02Click through your own screens — profile, settings, dashboard, any list of records, anything with a detail view.
3. 03For each request, open the Response tab and read the JSON. Not the preview of it; the body.
4. 04For anything shaped like a record, list the keys and compare them against the fields the screen actually uses.
5. 05Write down every key the UI does not need. Each one is either deliberate or a finding, and you now have to decide which.

Then check the endpoint outside your own front end, because your front end may be sending headers and parameters that flatter it. Request it directly and read the whole body.

# your own session, your own record — read every key that comes back
curl -s "https://yourapp.com/api/me" \
  -H "Cookie: <your session cookie>" | jq 'keys'

# the same for a list endpoint: what does ONE element carry?
curl -s "https://yourapp.com/api/projects" \
  -H "Cookie: <your session cookie>" | jq '.[0] | keys'

The field names worth reacting to immediately: anything containing password, hash, secret, token, key, email, phone, address, stripe_, is_admin, role or internal_. A password hash in a response is an emergency; an internal role flag is an invitation to try changing it.

There is one correct place for this fix and it is the line that fetches the data. Filtering in the component, deleting keys before rendering, or hiding fields with CSS all leave the payload untouched.

// Supabase — before
const { data } = await supabase.from("profiles").select("*").eq("id", id);
// after
const { data } = await supabase
  .from("profiles")
  .select("id, display_name, avatar_url")
  .eq("id", id);

// Prisma — before
const user = await prisma.user.findUnique({ where: { id } });
// after
const user = await prisma.user.findUnique({
  where: { id },
  select: { id: true, displayName: true, avatarUrl: true },
});

// raw SQL — before
SELECT * FROM users WHERE id = $1;
// after
SELECT id, display_name, avatar_url FROM users WHERE id = $1;

If reshaping every query is too large a change today, put one serialiser between your records and your responses and route everything through it. An allowlist there fails closed: a column added to the table later does not silently appear in the API.

function publicProfile(row) {
  return {
    id: row.id,
    display_name: row.display_name,
    avatar_url: row.avatar_url,
  };
}
// every handler returns publicProfile(row), never row

If you only have twenty minutes, spend them here. These are the endpoints where we find wide responses most often in apps built with coding agents.

1. 01/api/me, /api/profile or whatever loads the signed-in user. Almost always the whole row.
2. 02Any list endpoint — /api/projects, /api/orders. A wide response is multiplied by every element in the array.
3. 03Search and autocomplete. Built quickly, rarely reviewed, and frequently returns full user records to match on a name.
4. 04Anything with a member or team list, where other people’s email addresses are the usual find.
5. 05Webhook and integration callbacks, which tend to hold the identifiers of your payment provider and your own internal flags.