A backend that hands its full internal object straight to `JSON.stringify` or an ORM's default serializer and calls that the API response is making a bet: that the frontend consuming this response will only ever display the fields it means to, and that no other consumer will ever read the response directly. Both halves of that bet fail constantly in practice — a mobile app that only renders a user's display name still receives the full user object over the wire, including the password hash, the internal role flag, and any field the model has ever grown, because the response was never actually shaped for what the endpoint was supposed to reveal, only for what the frontend happened to choose to render.
This is excessive data exposure, and unlike mass assignment's mirror-image failure on the request side, it is often invisible in normal testing, because the application under normal use behaves correctly — the UI never displays the extra fields, so nobody notices they were sent. The exposure only becomes visible the moment someone opens their browser's network inspector, intercepts the raw response with a proxy tool, or simply reads the API documentation closely enough to notice a field the UI never shows. Filtering sensitive data must happen on the server, in the response the API actually sends, not in the client that happens to be well-behaved about what it renders.
Analogy🏏Cricket
🏏 Think of it like cricket: A broadcaster's production truck receives one unified camera and data feed from every source at the ground — every camera angle, every microphone, the full biometric feed from a player's wearable heart-rate sensor, the coaching staff's private radio channel — and trusts that the vision mixer in the truck will only ever select the clean, approved angles for the actual broadcast. This works fine as long as the vision mixer behaves exactly as intended, but the moment anyone else gets access to that raw, unified feed directly — a technician's laptop left logged into the wrong system, a signal leak somewhere upstream of the mixer — everything in it is exposed exactly as it exists, including the private coaching radio and the biometric data, none of which was ever meant to reach anyone outside the truck. A production operation that actually cares about what should and should not become public does not solve this by trusting the mixer to always behave; it solves it by never routing the private radio channel and the biometric feed into the same unified signal the public broadcast is built from in the first place — building the broadcast feed, from the source, out of only what is meant to be public. Just as trusting the vision mixer to always select correctly leaves the raw feed's private channels exposed to anyone who bypasses the mixer, trusting a frontend to only render approved fields leaves an API response's sensitive fields exposed to anyone who reads the raw response directly. Just as the durable fix is building the public feed from only public sources at its origin, the durable fix for an API is building the response, on the server, from only the fields meant to be exposed, rather than sending everything and trusting a well-behaved consumer to look away from the rest. The insight is that a boundary a well-behaved client happens to respect is not a boundary at all — the server is the only party positioned to actually enforce what leaves the building.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.