A 200 with an empty list is still a leak

A common pattern looks clean in the UI. The service runs a broad query, returns every matching row, and the client hides the ones this user should not see. The screen shows a short list, sometimes an empty one. The network tab shows the rest. Status 200, full payload, then a filter that never left the browser.

That filter is not authorization. Anyone who can call the endpoint can skip the UI and read every row. Authorization has to happen before the query, or as a server-side row filter taken from policy. The database, search index, or service that owns the records should return only what this caller may see. The client should not be trusted to throw the rest away.

The same gap shows up wherever a client can ask for more than it displays. Search that hits an unscoped index can leak titles, identifiers, and fragments. An export that reuses the unrestricted query just packages the leak as a file. An admin dashboard that loads every tenant and then hides other tenants still delivered those records to the browser.

Check the response body, not only the status code. A 200 with someone else's data, or with an empty list that was produced by hiding rows in the UI, is still a leak.