Make Sure Each Customer Sees Only Their Own Information
A beginner-friendly guide to separating customer records in an AI-built app, testing the rules with two accounts, and checking them after changes.
before you start
Signing in identifies a customer, but every saved item still needs rules that say who may see or change it.
Understand the rule your customers expect
in plain words
A customer who signs in should receive only the information that belongs to their account or approved team.
Imagine that your app stores appointments, orders, notes, messages, or customer details for many people. Each person expects to see only their own items after signing in. That separation must hold everywhere: on the main screen, in search results, on an item opened from a saved address, and when the app quietly loads information in the background. Hiding other customers’ items on one screen is not enough. The place that stores the information must check who is asking every time something is viewed or changed.
Supabase can apply that check to each saved record. The technical name is Row Level Security, commonly shortened to RLS. A row means one saved record, such as one order or one note. When this protection is configured correctly, Supabase compares the signed-in account with the owner of that record before allowing an action. This creates a dependable boundary even when an AI builder later adds a new screen or search feature.
- ▸Name the owner of every kind of saved information.
- ▸Mark each item as personal, shared with a specific team, or available only to approved staff.
common risk
The main screen displays only the current customer’s orders, but the saved orders have no ownership rule. A search screen added later can accidentally return orders from every customer.
what to do now
Make an inventory of your tables and file areas. For each one, write who may view, create, change, and delete its contents.
ask your AI
Review my Supabase project as a multi-user app. First list every table and file area that stores customer or business information. In plain language, state who should be allowed to view, create, change, and delete each kind of item. Then identify anything without a clear owner or sharing rule. Do not change the project yet; show me the proposed rules first.
Connect every saved item to the right person
in plain words
Each saved item needs a trustworthy link to the person or team allowed to use it.
For personal information, every saved record should contain the identity of its owner. That identity should come from the account that is currently signed in. It should not come from a name, email address, or owner number submitted by a page, because a person can alter those fields or an AI builder can connect them incorrectly. When someone creates a note, order, or profile entry, the app should attach the signed-in account automatically.
Shared information needs a slightly different design. A project may belong to a workspace, and several people may belong to that workspace. Keep a protected membership list showing which accounts belong to which group and what each person may do. The technical name for a saved rule that decides whether an action is allowed is a database policy. A good policy can be explained simply: the person owns this record, belongs to its approved group, or has a clearly assigned staff role.
- ▸Use the signed-in account identity as the owner instead of trusting a form field.
- ▸For shared work, check membership in the correct team before returning or changing an item.
common risk
A form sends an owner number when saving a note. If that number is wrong or changed, the note may appear in another customer’s account or disappear from the person who created it.
what to do now
Inspect one example from every table that holds personal information. Confirm that it records an owner supplied by the signed-in account, not by an editable field.
ask your AI
Inspect my Supabase tables and the code that creates records. Make every personal record receive its owner from the currently signed-in account, never from an editable page field. For shared records, use a protected membership table to confirm that the person belongs to the correct workspace. Explain the proposed changes in plain language, apply them, and list every table changed.
Decide separately who can view and who can change
in plain words
Permission to see an item should not automatically include permission to edit or remove it.
Consider four actions separately: viewing an item, creating one, changing one, and deleting one. A customer might create a support request and read it afterward, while only approved staff may change its status. A team member might read a shared task but not delete the whole project. If one broad rule covers everything, someone may receive more power than you intended.
In Supabase, enable the record-checking protection on every table that holds customer or business information. Then create a narrow rule for each action you want to allow. Developers call these rules policies. A personal-record policy should compare the signed-in account with the stored owner. A shared-record policy should also verify membership in the correct group. Staff powers should depend on a protected role, not on a button being hidden. Refuse an action when no clear rule allows it; do not treat a missing rule as permission.
- ▸Review viewing, creating, changing, and deleting as four separate decisions.
- ▸Give staff powers only through protected, clearly defined roles.
common risk
Customers can view only their own profiles, but the rule for changing profiles does not check the owner. A person could then change someone else’s saved profile even though it never appears on their normal screen.
what to do now
Write one plain sentence for every allowed action on every table, and compare those sentences with the rules actually configured in Supabase.
ask your AI
Audit every Supabase table that stores customer or business information. Show the current rules for reading, adding, changing, and deleting in plain language. Flag any action that does not verify the record owner, the correct workspace membership, or an approved staff role. Add the narrowest missing policies, keep the four actions separate, and provide a table-by-table summary of what changed.
Prove the separation with two customer accounts
in plain words
Two ordinary test accounts can reveal whether one customer can reach another customer’s information.
Create two test accounts that represent different customers, such as Alex and Sam. Give each account clearly labeled sample notes, orders, or appointments. Sign in as Alex and confirm that Sam’s items do not appear in lists, search results, detail screens, downloads, or file areas. Try to change and delete only through normal features your app provides, and confirm that Sam’s items remain unavailable. Then repeat the same checks while signed in as Sam.
Developers call this access testing: confirming that permitted actions work while forbidden actions are refused. Repeat it whenever your AI builder adds a table, search, sharing option, export, file area, or staff feature. Also test an account that belongs to a shared team and one that does not. A beautiful screen can hide an incomplete saved-data rule, so record the account used, the action attempted, the expected result, and the actual result.
- ▸Use two ordinary accounts with different, clearly labeled records.
- ▸Test every way the app can list, open, search, download, change, delete, or share information.
common risk
A newly added search box finds every saved note because its table was created without the same ownership checks used by the original note screen.
what to do now
Run the two-account test before inviting customers and after every meaningful change involving saved information or files.
ask your AI
Create and run a two-account safety test for my app using ordinary accounts named Test Alex and Test Sam. Give each account separate sample records. Check lists, detail screens, search, editing, deletion, downloads, shared workspaces, and uploaded files that exist in the app. Confirm that neither account can view or change the other account’s personal items. Report each test step, expected result, actual result, and any correction made.
Keep powerful passwords and keys out of visitor files
in plain words
Files delivered to visitors should have limited power, while database passwords and payment keys stay in a protected part of the app.
A visitor’s device may need a limited public setting so the app can communicate with Supabase. That setting is not the same as a database administrator password, payment key, or access code that can open many records or spend money. Files sent to a visitor can be inspected and copied. Powerful passwords and keys must instead stay in a protected part of the app that runs away from the visitor’s device. Developers call that protected location the server.
Never use a powerful key as a quick fix for a missing ownership rule. In Supabase, one especially powerful key is technically called the service role key; it can bypass the normal record checks and must never be included in visitor-delivered files. Replace any exposed password or key, because moving it does not cancel copies already made. After publishing, VibeCodeWall can check the public app from the outside and watch for important changes over time. It does not see private code, so continue the account tests and Supabase reviews as well.
- ▸Store database administrator passwords and payment keys only in protected server settings.
- ▸Replace an exposed powerful password or key instead of merely moving it.
- ▸Combine outside monitoring with repeated two-account checks.
common risk
An AI builder places a powerful Supabase key in a file sent to visitors to make a permission error disappear. Anyone who receives that file could copy the key and bypass the customer-separation rules.
what to do now
Ask your AI builder to inspect visitor-delivered files and public project settings, move any powerful password or key to protected server settings, replace exposed values, and restore narrow record rules.
ask your AI
Inspect my app for database administrator passwords, payment keys, access codes that open customer information, and the Supabase key technically called the service role key. Check all files delivered to visitors and all public project settings. If any powerful value appears there, remove it, place the needed operation in protected server-side code, replace the exposed value in its provider dashboard, and restore narrow Supabase ownership policies. Do not print the full value in your report. List each location checked and each correction made.
Quick checklist
- 01List every place where your app saves customer information.
- 02Decide who owns each type of saved item.
- 03Make every new item receive its owner automatically from the signed-in account.
- 04Write separate rules for viewing, creating, changing, and deleting information.
- 05Test with two ordinary customer accounts, not an administrator account.
- 06Check lists, detail screens, searches, downloads, and uploaded files.
- 07Keep database administrator passwords, payment keys, and data-opening access codes away from files visitors can download.
- 08Repeat the two-account test after important app changes.
- 09Use VibeCodeWall to check the public app from the outside and watch for important changes over time.
FAQ
Is signing in enough to separate customer information?
No. Signing in identifies the person. Supabase still needs saved rules that decide which records that person may view or change.
Does every table need these rules?
Review every table. Any table containing customer or business information should have explicit rules for every allowed action.
Can several people safely share the same project?
Yes. Store a protected membership list and confirm that the signed-in person belongs to the correct project before allowing an action.
Why should I repeat the tests after the app is published?
New screens, tables, searches, sharing features, and files can change who can reach information. Repeat account tests and use outside monitoring to notice important changes.