Keep Each Customer’s Information in the Right Account
Your app may let people sign in but still mix their notes, orders, bookings, or profiles. Learn how to separate saved information and test the result with two ordinary accounts.
before you start
Signing in tells your app who a person is. Separate rules must decide which notes, orders, bookings, or profiles that person may see and change.
Understand how information can end up in the wrong account
in plain words
When several people use one app, each person must receive only the notes, orders, bookings, messages, or profiles meant for them.
An app can appear to work perfectly while only you use it. The risk becomes visible after a second person joins. A customer might open an order list and see another customer’s order. A member might change a note written by someone else. Signing in does not automatically prevent this. It only tells the app which account is present. Your app still needs a separate decision for every saved item it returns or changes.
Supabase keeps saved information in organized groups. Developers call this organized storage a database, and each group is called a table. A table might hold profiles, bookings, tasks, messages, or orders. Supabase can examine one saved item at a time and decide whether the current person may use it. The technical name is Row Level Security, often shortened to RLS. It places the decision beside the saved information, so protection does not depend only on whether a screen hides a button or filters a list.
- ▸Write down every kind of information your app saves about a person.
- ▸For each kind, state who should be allowed to see or change it.
common risk
A task list was created when only the app owner used it. After customers join, the list returns every task, so one customer can read another customer’s task names and due dates.
what to do now
Make a simple inventory of your profiles, notes, bookings, messages, orders, and uploaded-file details. Write the allowed people beside each item.
ask your AI
Review my Supabase app and list every table that stores profiles, notes, bookings, messages, orders, uploaded-file details, or other information belonging to a signed-in person. For each table, explain in plain language who should be allowed to view, create, edit, and delete each record. Do not change anything yet. Point out any table where the ownership rule is missing or unclear.
Mark who owns every saved item
in plain words
Each note, booking, message, or order needs a dependable account label so the app knows where it belongs.
Picture one booking as a line in a notebook. That line needs a trustworthy label that identifies its owner. Without the label, the app cannot reliably separate one customer’s booking from another’s. A display name is not enough because two people can use the same name. An email typed into a form is also weak proof because someone can type another person’s address. The ownership label should come from the account that has already signed in.
Supabase gives each signed-in account a stable identity. The technical name is a user identifier. Save that identifier with every item that belongs to one person. When a new note or order is created, Supabase should use the identity of the current account instead of trusting an owner value submitted by the visitor’s screen. The screen is the visible part people tap or click; it can request an action, but it should not be allowed to choose who owns the result. Also decide how shared records work, such as a booking visible to both a customer and an assigned staff member.
- ▸Use the signed-in account’s stable identity as the ownership label.
- ▸Write a deliberate rule for shared items instead of leaving ownership uncertain.
common risk
An order form accepts an owner label chosen by the visitor. A person changes that label, and the new order appears inside another customer’s account.
what to do now
Inspect sample records in every person-owned table and confirm that each one has an owner field filled from the signed-in account.
ask your AI
Update every person-owned table in my Supabase app so each new record stores the current signed-in user identifier as its owner. Do not trust an owner identifier submitted by a form, page, address bar, or visitor-controlled request. Explain how existing records without an owner will be handled safely. Show the proposed database changes and app changes before applying them.
Choose what each person may do
in plain words
Viewing, adding, editing, and removing information are separate decisions and should be checked separately.
A customer may need to read a booking but may not be allowed to cancel it after the appointment begins. A support worker may need to view a customer’s question without changing the customer’s profile. Someone who can add a comment should not automatically be able to edit every comment. Treat viewing, adding, editing, and removing as four separate choices. Give each person only the actions required for the app to work.
Supabase expresses each choice as a database rule. The technical name is a policy. A policy can cover reading, adding, editing, or removing saved items. Supabase documentation may call these actions select, insert, update, and delete. Start with the smallest useful rule: an ordinary signed-in person may use only an item whose owner identifier matches that person’s identifier. Then add carefully defined exceptions for real needs, such as an assigned staff member viewing a support request. Avoid one broad staff rule if different staff jobs need different information.
- ▸Decide viewing, adding, editing, and removing one action at a time.
- ▸Create narrow exceptions only for a real staff or sharing need.
common risk
Members need to add their own comments, but one broad rule also allows them to edit or remove comments written by every other member.
what to do now
Create four written answers for every table: who may view, add, edit, and remove an item.
ask your AI
Create Supabase Row Level Security policies for every person-owned table in my app. Separate SELECT, INSERT, UPDATE, and DELETE. An ordinary signed-in user may act only on records whose owner identifier matches the current user identifier. For INSERT and UPDATE, also prevent the owner identifier from being changed to another account. List any staff or shared-record exception separately, explain every policy in plain language, and show the SQL before applying it.
Prove the separation with two ordinary accounts
in plain words
Testing as two different customers reveals mistakes that your app-owner account may hide.
Your app-owner account may have powers that an ordinary customer does not. If you test only with that account, a missing rule can look like correct behavior. Create two test accounts that contain no real customer information. Give each account clearly different sample records, such as a blue notebook entry for one and an orange entry for the other. This makes accidental mixing easy to notice.
Use the first account to check lists, individual detail pages, searches, creation forms, editing, and removal. Refresh each important page and open saved page addresses directly. Then repeat every check with the second account. Do not accept a hidden menu item as proof, because a hidden button does not necessarily protect the saved information. The technical name for checking whether the right person is allowed and the wrong person is refused is authorization testing. Record the expected result before each test, including a clear refusal when one account tries to use the other account’s sample item.
- ▸Use two ordinary test accounts with clearly different sample information.
- ▸Test direct page opening and every action, not only visible menus.
common risk
Each account’s main list looks correct, but a saved address for an individual booking opens the other account’s booking details.
what to do now
Run the same written test with both accounts and correct every case that reveals or changes the other account’s sample information.
ask your AI
Create a two-account test plan for my Supabase app using Account A and Account B with safe sample data. Cover lists, individual detail pages, search, creating, editing, deleting, page refreshes, and opening saved page addresses directly. Include attempts by Account A to view or change Account B’s records and the reverse. State the expected result for every test and include checks that confirm refused actions do not change saved data.
Repeat the checks whenever the app changes
in plain words
A new feature can add saved information without the rules that keep one person’s information away from another.
An AI builder may add favorites, notifications, conversations, generated documents, or file details when you request a new feature. That feature may also create a new table even if you never asked for one by name. Treat every new place that saves information as a fresh ownership decision. Before publishing the change, confirm who owns each item, what an ordinary person may do, and whether Supabase checks every affected record.
Also examine the files delivered to visitors. Passwords, payment keys, and access codes that can open customer information or spend money must stay in a protected part of the app that visitors cannot download. Developers call that protected part the server side. After meaningful changes, repeat the two-account checks. VibeCodeWall checks the public app from the outside; it does not see private code. It can keep watching the public app for important changes over time. That outside view supports your own ownership review and account tests, but it cannot replace them.
- ▸Review ownership whenever a feature adds or changes saved information.
- ▸Combine repeated two-account tests with ongoing checks of the public app.
common risk
A new favorites feature appears to work, but its table has no active per-record rules and sends one member favorites saved by other members.
what to do now
Add a before-publishing check for every changed table, every delivered file, and both ordinary test accounts. Continue watching the public app afterward.
ask your AI
Before I publish this change, inspect every new or changed Supabase table and every feature that saves profiles, favorites, notifications, conversations, documents, orders, bookings, messages, or file details. Confirm who owns each record, whether Row Level Security is enabled, and whether separate SELECT, INSERT, UPDATE, and DELETE policies are present. Create a two-account test checklist. Also flag any password, payment key, or access code that can open data or spend money if it could be included in files delivered to visitors. Explain each finding in plain language and do not weaken existing protections.
Quick checklist
- 01List every kind of customer, member, order, booking, message, or profile information your app saves.
- 02Decide who may view, add, edit, and remove each kind of saved information.
- 03Confirm that every person-owned item records the identity of the account that owns it.
- 04Turn on Supabase’s per-record rules for every table that contains information belonging to a person.
- 05Test every important screen and action with two ordinary accounts.
- 06Check saved detail pages, searches, page refreshes, editing, and removal as both test users.
- 07Keep passwords, payment keys, and access codes away from files that visitors receive.
- 08Check the public app from the outside after important changes and continue watching it over time.
FAQ
Does signing in automatically separate each customer’s information?
No. Signing in identifies the current account. Separate per-record rules must decide which notes, orders, bookings, messages, or profiles that account may view or change.
Does every Supabase table need the same rules?
No. Review every table, but choose rules based on what it contains. Person-owned information usually needs ownership checks, while intentionally public information needs a clearly documented public rule.
Is testing with my app-owner account enough?
No. Use two ordinary accounts as the main test because an app-owner account may have wider powers that hide a mistake.
What should I check after adding a feature?
Find every new kind of saved information, decide who owns it, define each allowed action, confirm the rules are active, and repeat the two-account tests before publishing.