Before You Launch a Vibe-Coded Supabase App, Run This Two-User Data Test

Your AI-built app can have a polished dashboard, working sign-in and a convincing demo while still exposing one customer's data to another. Before sharing a public launch link, test the permission boundary—not just the interface.

For makers using Supabase, a useful starting point is a three-identity test: signed out, signed in as user A and signed in as user B. This guide turns that idea into a small release gate. It is a focused security check, not a complete audit or a guarantee that an app is safe.

Sign-in is not the same as data isolation

Authentication establishes who a user is. Authorization determines what that user may read or change. Hiding another user's records in a component does not establish a server-side access boundary. The underlying API must enforce the same rule even when the request does not come from your normal page.

Supabase's official data-security guide recommends Row Level Security for exposed tables and grants limited to the privileges each role needs. A publishable key identifies the project; it is not a substitute for those policies. Older projects may use an anon key with the same important distinction.

First, check which keys reach the browser

A publishable key is designed for client use when access controls are configured correctly. Secret and service-role keys are different: Supabase warns that they bypass RLS and must never be exposed on the frontend.

Inspect the environment-variable conventions of your framework and the built client bundle. A variable that looks private in a development file may be bundled into browser code if it uses a public prefix. Keep privileged credentials in approved backend secret storage. If one has already been exposed, remove it from the client, rotate it and investigate the exposure; deleting a line from the current source does not revoke a leaked key.

Define a rule that can actually be tested

Write a sentence for each sensitive resource. For a private notes app: “A signed-in user may read, create, edit and delete only their own notes.” For a shared workspace, membership and role may matter instead of individual ownership. Public catalog entries may deliberately be readable without sign-in while remaining writable only by authorized staff.

Do not copy a policy from an unrelated app until you have decided which rule fits yours. Check both table privileges and row policies. A policy that correctly restricts reads does not automatically express the intended rules for inserts, updates and deletes.

The three-identity test

Use a staging environment with synthetic records. Create two ordinary accounts, A and B, and one clearly labeled record owned by each. Do not perform this experiment against other people's applications or real customer data.

1. Signed out: try the app's normal read and write operations. Private data should not appear. Public resources should behave exactly as your rule permits.
2. User A: confirm A can perform the allowed actions on A's record. Then use the app's API test setup to request B's test record and attempt each operation your rule prohibits.
3. User B: repeat the test in the opposite direction. This catches fixtures or implementation assumptions that accidentally favor the first account.
4. Ownership changes: test whether an update can move a record to another owner or workspace when it should not. Do not stop at testing the initial record lookup.
5. New records: check whether a user can create a record with another user's owner identifier. The server-side policy must enforce the intended relationship.

Use ordinary user credentials for these tests. Testing through a privileged server client that bypasses RLS can produce misleading results. Record the expected outcome, actual outcome and relevant policy for each case. A denied request may surface differently across API operations, so verify the data did not change rather than relying on one expected HTTP status alone.

What to ask an AI coding agent to do

Give the agent a bounded task: inventory the exposed tables, describe the current ownership rules and add tests for the two-user boundary. Ask for a reviewable explanation of each policy change. Require it to preserve intentionally public data and existing legitimate access.

“Using synthetic fixtures, test that user A cannot read or modify user B's private records through the same client access path used by the app. Include create, update and delete cases. Do not disable RLS, use a service-role key to make tests pass or change unrelated features. Report the failing cases before proposing a minimal fix.”

This is more useful than asking “make the app secure.” It produces evidence you can inspect and a regression test you can rerun after future AI-generated changes.

Make the boundary part of the launch checklist

• Each sensitive table has an explicit access rule.
• Exposed tables have the intended grants and RLS policies.
• No privileged database or service secret is shipped to the client.
• Signed-out and cross-user tests behave as intended.
• Legitimate user workflows still work after the policy change.
• Storage, backend functions and other access paths receive their own review.

When you share a project on MakerPad, a working demo is the beginning of the story. A small, repeatable authorization test helps make the product behind that demo more trustworthy. It does not replace broader testing for payments, uploads, abuse, backups and privacy.

Source and scope

Based on Supabase: Securing your data, accessed October 6, 2026. Consult the linked Row Level Security reference for policy syntax and operation-specific behavior. This is an evergreen maker checklist, not a report of a newly announced incident or a claim that any particular MakerPad project is vulnerable.