Supabase returns another user’s private rows

1. Identify the table and project.

   In Chrome Network, open the request that returns the private test row. Read its destination project and table path. Match those to your Supabase dashboard before inspecting policies; similarly named projects can have different rules.

2. Classify the client credential.

   In the project’s API key settings, identify whether the browser uses a publishable or legacy anon key. Those client keys are expected to be visible. A secret or service_role key is privileged and must not be shipped to the browser; stop and rotate it if exposed.

3. Inspect the table’s read protection.

   Open the table’s RLS policies in the dashboard. Confirm row level security is enabled and inspect every applicable SELECT policy. For a single-owner row, compare the owner column with auth.uid(), which identifies the requesting user. Look for broad rules that permit unrelated users.

4. Try the harmless row under both identities.

   Use the app as its owner, then sign into the second account in an incognito window and open the same test item. Inspect the actual response in that window. Record whether the owner gets the row while the other account receives no private row content.

WORKSAn ordinary client reads its permitted row while the unrelated account cannot retrieve it.

BROKENThe Data API returns private row content to the unrelated identity.

Ranked in the order to investigate, not by claimed frequency.

1. RLS is off or a read policy is too broad.

   Enable RLS on the exposed table and define the intended read permission. For private owner-only data, bind access to the authenticated owner. Review all applicable policies so a permissive rule does not leave the unwanted access in place.

2. The client uses a privileged key.

   Revoke or rotate that key, replace browser usage with a publishable key, and move privileged work to an authorized backend. Then repeat the two-account read; key replacement alone does not establish that policies are correct.

3. The owner field is missing or wrong.

   Repair how ownership is assigned and validate it on creation and updates. Keep SELECT, INSERT, UPDATE and DELETE decisions explicit instead of treating a successful read test as proof for all four operations.

• Workspace-shared tables need membership rules that reflect the product. Replacing those with a single-owner comparison may block legitimate collaborators.
• A server endpoint using elevated credentials requires its own access checks. Passing the browser Data API test does not prove that endpoint is safe.

When to stop and hand it over

Stop after the first unauthorized disposable-row read. Restrict the affected operation and ask for a policy review if multiple tables, membership rules or privileged server routes are involved. Supply table names and redacted policy definitions, never the service key.