Make Sure Customers Cannot See or Change Each Other’s Information
Use two safe test accounts to check every screen, search, file, link, and editing action before trusting your app with real customer information.
before you start
Signing in is only the first step. Your app must protect customer information whenever someone views, changes, downloads, or deletes it.
Understand what must stay separate
in plain words
Each customer should see and change only the information that belongs to their account.
Imagine that your app manages appointments, orders, invoices, notes, or projects. A customer expects to find only their own names, files, totals, and messages after signing in. They should never see another customer’s information, even by accident. Before inviting real people, create two test accounts. Give them unmistakably different invented records, such as Blue Studio with Tuesday appointments and Green Market with Friday appointments. Never use real customer information for this test.
Sign in as Blue Studio and inspect the app, then repeat as Green Market. The goal is to prove that each customer has a separate space even though both use the same app. Developers call this multi-tenant data isolation. That means information belonging to one customer remains separated from information belonging to every other customer when it is displayed, searched, changed, downloaded, or removed. A successful sign-in screen alone does not prove that this separation works.
- ▸Use invented names and records that are easy to tell apart.
- ▸Write down which screens each account can open and what should appear.
common risk
Blue Studio signs in and sees Green Market’s appointment in a recent-items list.
what to do now
Create two test accounts today and add at least three clearly different records to each one.
ask your AI
Create two safe test accounts named Blue Studio and Green Market with at least three clearly different sample records each. Review my app so a signed-in customer can see only records belonging to that customer. List every screen and data action you checked, describe any changes you make, and do not use real customer information.
Check every place information can appear
in plain words
Customer information may appear in searches, messages, totals, files, and shared links as well as the main screen.
Begin with the places people use most: the home screen, lists, record details, search results, reports, messages, and recent activity. Then check less obvious places, including printable pages, exported files, shared links, dashboard totals, and emails sent by the app. Use both test accounts in every place. Names, totals, attachments, and messages should always match the account currently in use. A total can reveal another customer’s activity even when no names are shown.
Do not stop because a list looks correct. Open a record from search, click a message, use a saved bookmark, and revisit a page through the browser history. Test every report and attachment too. Hiding a button is not enough; the app must refuse a request for another customer’s information. Developers call this an authorization check. It means the app confirms that the signed-in person is allowed to see the particular record or file each time it is requested.
- ▸Test lists, details, searches, reports, messages, files, and shared links.
- ▸Check totals, empty screens, and error messages for clues about other customers.
common risk
Green Market cannot see Blue Studio in the main list, but a search result shows Blue Studio’s name and order total.
what to do now
List every screen, email, file, and link that can reveal customer information, then test each one with both accounts.
ask your AI
Find every feature in my app that can show customer information, including lists, record details, search, reports, totals, emails, notifications, exported files, attachments, and shared links. Make each feature verify that the signed-in customer owns the requested record before revealing any information. Add automated tests using Blue Studio and Green Market and show me the expected result of every test.
Test whether one customer can change another customer’s records
in plain words
The app must prevent customers from editing, deleting, or creating information in someone else’s account.
Next, test actions that create, edit, cancel, delete, upload, approve, or mark a record complete. Make a harmless change to a Blue Studio sample record. Sign in as Green Market and confirm that the change is neither visible nor reversible there. Repeat in the opposite direction. If employees use the app, create separate employee test accounts and write down exactly which customers each employee should be able to help. Test those limits instead of assuming job titles apply them correctly.
Pay special attention to forms that let someone choose a customer, project, or company. Whenever possible, the app should determine the customer from the signed-in account rather than trusting a choice sent from the page. Developers call the protected saving area the server, and they call its repeated ownership decision server-side authorization. In plain language, the part that actually saves the change must confirm ownership again. A page can look restricted while its saving action still accepts the wrong customer’s record.
- ▸Test creating, editing, deleting, uploading, approving, and changing status.
- ▸Confirm that ownership is checked when a change is saved, not only when the page opens.
common risk
A customer edits their own order, but the saving action changes another customer’s order after the wrong record is selected.
what to do now
Perform one harmless create, edit, and delete test in each account, then confirm that the other account remains unchanged.
ask your AI
Review every create, edit, delete, upload, approval, cancellation, and status-change action in my app. In the protected saving logic, determine the customer from the signed-in account and verify that the affected record belongs to that customer. Do not trust a customer number, hidden field, record number, or company choice sent by the page. Add tests proving Blue Studio cannot change Green Market records and Green Market cannot change Blue Studio records.
Treat every customer link and file like a locked door
in plain words
A customer link or file must be checked each time someone tries to open it.
People copy links into messages, save bookmarks, and receive links by email. Customer files may include invoices, photos, reports, or documents. Open each test link while signed in as the other customer and while signed out. The app should refuse to show the information. A long or difficult-to-guess file address is not protection. The app must check the person requesting the file before every opening or download, including after a link has been forwarded.
Passwords, payment keys, and access codes that can open information or spend money must stay in a protected part of the app that visitors cannot download. Customer files need their own checks too. Developers call the rule that decides who may use a specific page, file, or action access control. This decision must happen at the moment of the request. Do not treat possession of a link, knowledge of a file name, or a hidden button as proof that someone is allowed in.
- ▸Open customer-specific links from the other test account and while signed out.
- ▸Require a fresh ownership check whenever a customer file is opened or downloaded.
common risk
A link to Blue Studio’s invoice opens for Green Market because possession of the file address is mistaken for permission.
what to do now
Test every customer-specific link and file using the wrong account and a signed-out browser window.
ask your AI
Make every customer-specific link, invoice, report, image, export, and attachment check the currently signed-in customer before opening or downloading. Refuse the request without revealing the other customer’s name or record details. Keep passwords, payment keys, and access codes that can open information or spend money only in protected app storage that visitors cannot download. Add tests for the correct account, the wrong account, and a signed-out visitor.
Save the results and repeat the test after changes
in plain words
Customer separation can break when you add or change a feature, so checking once is not enough.
Keep a short test record containing the two account names, every place checked, each action attempted, the expected result, and the actual result. Screenshots containing only invented information can help. Repeat the routine when you add a screen, report, file type, import, connected service, employee role, or major AI-generated change. Fix every unexpected or unclear result before inviting more customers. A repeatable record is more dependable than trying to remember what you tested months earlier.
An outside check can add another layer of awareness. VibeCodeWall checks the public app from the outside and does not see private code. It can watch for important changes over time after you publish updates. This outside view cannot replace the two-account test because much of the separation becomes visible only after someone signs in. Use both: repeat the signed-in checks to prove what each customer can do, and keep outside monitoring active so important public changes do not pass unnoticed.
- ▸Keep a reusable test record with the expected result for both accounts.
- ▸Repeat every check after new features, imports, connected services, employee-role changes, and major updates.
common risk
A new report works during its first test but later combines totals from all customers after another app change.
what to do now
Save the two-account test as a required checklist and complete it before every important update reaches customers.
ask your AI
Create a repeatable pre-publication test checklist for Blue Studio and Green Market. Include lists, details, search, totals, emails, editing, deleting, uploads, downloads, shared links, customer files, signed-out checks, and employee screens. For every test, state the account to use, the action to perform, the expected safe result, and what evidence to save. Remind me to run the checklist after any important app change.
Quick checklist
- 01Create two test accounts with clearly different invented information.
- 02List every screen and action that uses customer information.
- 03Check what each account can see after signing in.
- 04Test searching, editing, deleting, downloading, and sharing from both accounts.
- 05Open customer links and files from the wrong account and while signed out.
- 06Ask your AI builder to check who owns a record before showing or changing it.
- 07Keep passwords, payment keys, and access codes out of files visitors can download.
- 08Repeat the full test after every important app change.
FAQ
Do I need two real customers for this test?
No. Use two test accounts with invented information. Make their records clearly different so any mix-up is easy to notice.
Is hiding a button or menu enough?
No. The app must check the signed-in person whenever information is viewed, changed, deleted, opened, or downloaded.
When should I repeat these checks?
Repeat them after changes to customer screens, searches, reports, files, sign-in, employee access, imports, connected services, or saving actions.
Can an outside check replace the two-account test?
No. An outside check watches the public app. The two-account test confirms what each signed-in customer can actually see and change.