Can a Supabase user read another user’s rows?
Yes, if sharing rules allow it, the execution role can bypass the intended policy, or another layer returns the data. Confirm the row should be private, then request its ID through both the Data API and the screen that showed it.
What to prepare
Give B’s fixture row a unique synthetic marker. Record the table or view, project and expected sharing rule. For example, an invited teammate may be a legitimate reader. Keep credentials out of the incident note.
Verification procedure
Isolate the user-level request
Fetch B’s row ID using A’s session and the publishable key. Repeat with B. If B receives the marker and A receives an empty list, this particular direct SELECT did not disclose the row to A.
Identify the path that disclosed the marker
If A’s screen still shows the marker, inspect the backend response, view, RPC and cache used by that screen. If the direct request also returns it, inspect RLS on that relation, applicable SELECT policies and A’s organization membership.
A diagnostic note for a list query on notes
B / Data API: 200, [{"id":"note-b","body":"Demo B"}]
A / Data API: 200, []
A / screen: “Demo B” visible → inspect backend and cacheDecision and limitations
Name the first boundary that returned the marker. Retest both paths after the fix and preserve access for a legitimate invited reader.
What remains unverified
This example assumes a list query, not .single(). An empty array without a working owner control is inconclusive.