Any filtering, hiding, or masking of sensitive data must happen in the API layer — in the server-side code that builds the response — before the data leaves the server.
The API layer is the only enforcement point that applies to all clients: web app, mobile app, direct API calls, third-party integrations, curl in a terminal, Burp Suite in a pentest. Everything calls the same endpoint.
If filtering only happens in the frontend JavaScript, any client that doesn't use that JavaScript — which is any client the developer didn't build — gets the unfiltered data.
The Peloton "privacy" setting controlled what the app displayed. It did not control what the API returned. From the API's perspective, private accounts and public accounts were identical — both returned the full profile object. Enforcement in the UI is not enforcement.
Imagine the API as a border crossing. Every piece of data that leaves your server must be checked at the border. The UI is a tour guide inside the country — useful, but the border check doesn't happen there. Sensitive data must be stopped at the API layer, not hidden in the app.
Any time a new field is added to a database object, ask your team whether that field needs to be protected from user writes. Schema changes are when this vulnerability most commonly gets introduced.