Stop One Customer from Seeing Another Customer’s Information
A page can look correct while showing the wrong person’s order, message, address, or file. Test two accounts side by side and make the app check who owns each item.
before you start
Before inviting real customers, confirm that every person can see and change only their own information, orders, messages, and files.
What keeping customers separate means
in plain words
Each signed-in customer should see and change only the information that belongs to that customer.
Imagine that Customer Ana and Customer Ben both use your app. Ana may have an address, an order, a support message, and an uploaded receipt. Ben may have similar items. When Ana signs in, the app must show only Ana’s items. It must also prevent Ana from changing, deleting, downloading, or sharing Ben’s items. The same rule must protect Ana when Ben signs in. This separation applies even when two customers have similar names or use the app at the same time.
You can check this without understanding how the app was built. Create two pretend customers through the same sign-up process real customers use. Give each account unmistakable sample information, such as “Ana Blue Order” and “Ben Orange Order.” Add a different file or message when those features exist. Never use real customer information for this test. Write down what each account should see and what it should be allowed to change before you begin.
- ▸Use names and sample items that are easy to tell apart.
- ▸Give both accounts enough information to test every customer feature.
common risk
Ben opens his order history and sees Ana’s delivery address because the app placed every customer’s orders in one list.
what to do now
Create two test accounts today and add at least one clearly different sample item to each.
ask your AI
Create a safe two-account test plan for my app. Use two pretend customers named Ana Test and Ben Test. List every customer page and identify which sample profile, order, message, address, payment record, and file each person should be able to view or change. Do not use real customer information.
Why every place and action matters
in plain words
The main page is only one place where another customer’s information might appear.
Check more than the first page after sign-in. Customer information can also appear in search results, recent activity, notices, account settings, support conversations, order summaries, file lists, email previews, printed reports, and pages opened from buttons. Test filters and sorting choices too. A protected profile does not help if a search result still displays another person’s phone number, or if a recent-activity box shows another person’s order. Make a list so small or rarely used areas are not forgotten.
Viewing is only half of the test. Try every normal action the app offers: edit an address, cancel an appointment, remove a message, replace a file, change an order, download a receipt, or share a document. After each action, check both accounts and confirm that only the intended item changed. The technical name for deciding whether a signed-in person may use a particular item or action is authorization. That decision must be made every time information is shown or changed.
- ▸Include search, notices, reports, files, and support messages.
- ▸Check both accounts after every change, deletion, download, or share action.
common risk
Ana cannot open Ben’s profile, but a search result shows Ben’s phone number and recent order.
what to do now
List every place that can show customer information and every button that can change it, then test the full list with both accounts.
ask your AI
List every place in my app that can show customer information, including profiles, searches, notices, recent activity, reports, messages, orders, account settings, file previews, and downloads. Then list every action that can edit, delete, cancel, replace, download, or share an item. Add a check before each action so the signed-in customer can use only items that belong to that customer. The technical name for this check is authorization.
A common way the rule fails
in plain words
Hiding another customer’s information on the screen is not enough; the app must check ownership before reading or changing it.
An app may remove Ben’s order from Ana’s visible list yet still accept a request to change that order. The screen and the protected part of the app have different jobs. The screen shows buttons and information to the visitor. The protected part retrieves stored information and saves changes. Developers call the second part the server. The server must compare the signed-in customer with the recorded owner before returning an item or accepting any change.
Developers call this repeated decision server-side authorization. The app should identify the person from the account that is currently signed in. It should not trust a customer name, customer number, or owner choice supplied by the visible page. Apply the same rule when reading, editing, deleting, downloading, or sharing. Passwords, payment keys, and access codes that can open information or spend money must stay in the protected part and must not be placed in files sent to visitors.
- ▸Base the decision on the account that is actually signed in.
- ▸Check the recorded owner before both viewing and changing an item.
common risk
The page hides Ben’s order from Ana, but the part that saves changes accepts Ben’s order number and updates it without checking its owner.
what to do now
Ask your AI builder to review every operation that reads or changes customer information and require an ownership check there.
ask your AI
Review every part of my app that reads, creates, edits, deletes, downloads, or shares customer information. In the protected server part, identify the signed-in account and compare it with the stored owner of the requested item before doing anything. Do not trust a customer number, owner value, or account name supplied by the visible page. If they do not match, return a calm message and make no change. Keep passwords, payment keys, and access codes out of files sent to visitors. Developers call this server-side authorization.
What to test now
in plain words
Test information, files, and changes separately because one feature can be safe while another is not.
Start as Ana and visit every area intended for customers. Confirm that Ana sees only Ana’s sample profile, order, messages, addresses, and files. Try each normal action that exists. Then sign out completely, sign in as Ben, and repeat the same checks. Reverse the test by confirming that neither account can reach or change the other account’s sample items. Use only the controls your app normally provides; you do not need to guess hidden addresses or force unusual requests.
Files deserve their own test. Check the file list, preview, download, replacement, deletion, and sharing options separately. Also test text information such as addresses and messages, plus business items such as orders, bookings, invoices, or payment records. Record the feature, Ana’s result, Ben’s result, and the expected result in a simple table. When the app blocks an action, confirm that it shows a clear message, reveals no other customer information, and leaves the item unchanged.
- ▸Test each type of information and each available action.
- ▸Record expected and actual results so the test can be repeated.
common risk
Only Ana can see the name of her receipt, but Ben can download the receipt from a shared file area.
what to do now
Run the complete two-account test and stop inviting customers until every unexpected result is corrected.
ask your AI
Build a two-account test checklist for my current app using Ana Test and Ben Test. Cover profiles, addresses, messages, orders, bookings, invoices, payment records, and files when present. For each feature, include viewing, searching, editing, deleting, cancelling, replacing, downloading, and sharing when available. State the expected result, provide a place to record the actual result, and require blocked actions to reveal nothing and make no change.
Keep checking when the app changes
in plain words
A new page or feature can accidentally mix customer information, so repeat the test after important changes.
Customer separation is not a one-time task. A new report, search box, support screen, mobile view, file area, payment feature, or AI-generated shortcut creates another place where the rule could be missed. Repeat the shorter two-account test whenever you change sign-in, customer records, files, searches, payments, staff abilities, or customer actions. Keep your expected results with your project notes so the next check is quick and consistent instead of depending on memory.
VibeCodeWall can add an outside view of the published app. It checks the public app from the outside and does not read the code used to build it. It can continue watching for important changes in what visitors can reach over time. This does not replace signed-in testing with Ana and Ben, because the two checks answer different questions. Use both, investigate any unexpected result, and repeat your customer-separation test before more people depend on a changed feature.
- ▸Repeat the test after changes involving customer information or account abilities.
- ▸Combine your signed-in checks with ongoing observation of the public app.
common risk
A new activity page is added months later and shows recent actions from every customer because nobody repeated the two-account test.
what to do now
Add the two-account check to every important change and keep watching the published app for unexpected public changes.
ask your AI
Whenever I change sign-in, customer profiles, messages, orders, bookings, files, searches, reports, payments, staff abilities, or customer actions, create a fresh two-account checklist before the changed feature is made available to customers. Compare the new feature with the existing ownership rules, identify every new place that shows or changes customer information, and remind me to repeat the public outside check with VibeCodeWall.
Quick checklist
- 01Create two test accounts with clearly different sample names.
- 02Add a different order, message, address, or file to each account.
- 03Check every page, list, search result, notice, and account setting.
- 04Test viewing, editing, deleting, downloading, and sharing wherever available.
- 05Confirm that a blocked action makes no change.
- 06Ask your AI builder to check the owner before showing or changing any item.
- 07Keep passwords, payment keys, and access codes away from files sent to visitors.
- 08Repeat the two-account test after every important change.
- 09Use only made-up information during testing.
FAQ
Do I need to understand programming to run this test?
No. You need two test accounts, clearly different made-up information, and a list of the normal pages and buttons available to each customer.
Is hiding another customer from a list enough?
No. The protected part of the app must check the recorded owner again whenever information is viewed, changed, deleted, downloaded, or shared.
Should I test staff accounts too?
Yes. Create sample staff accounts for each job type and confirm that each one can see and change only the customer information needed for that job.
Can VibeCodeWall confirm that every ownership rule is correct?
No. It checks the public app from the outside and watches for important changes over time. Use it alongside your own signed-in tests with two accounts.