Check That Customers Can Only See and Change Their Own Information

Your app may store appointments, orders, addresses, notes, uploaded files, invoices, team members, or preferences. Every saved item should belong to a specific customer account. When someone signs in, the app should show only the items connected to that account. It should apply the same rule when the person searches, downloads a file, changes a setting, or opens a saved link. Developers call this tenant isolation: keeping each customer’s information in its own app space.

Signing in answers who the person is, but it does not automatically answer which information that person may use. The app must make that second decision for every item and every action. The technical name is authorization: deciding whether a particular signed-in person may view or change a particular item. This matters even in a small app. One missed check can expose a customer’s address, invoice, document, message, or business record to someone from another account.

Create two customer accounts made only for testing. Do not copy real names, addresses, files, or payment details into them. Give the first account items with an obvious label such as Red Company and give the second items labeled Blue Company. Add at least three records, one uploaded file, and different settings to each account. Before testing, note what each account is supposed to see. Clear differences make a wrong result easy to recognize without reading technical reports.

Sign in to the first account and visit the app through its normal menus. Check the home page, lists, item details, search, filters, recent items, notifications, reports, and files. Sign out completely before entering the second account and repeating the process. Also try refreshing pages and using the browser’s Back button. Each account should encounter only its own sample information. A missing item should not reveal another customer’s name, owner, filename, amount, or other details.

Make an inventory of every place where customer information can appear. Include list pages, individual records, search suggestions, filtered results, totals, charts, reports, exports, attachments, shared pages, emails, notifications, and error messages. Test each place with both accounts. A refusal should reveal as little as possible. For example, saying that an item is unavailable is safer than confirming its title, customer name, price, or filename to a person who should not know it exists.

Pay special attention to links copied from the address bar, bookmarks, and messages. First open a Red Company item while signed in to Red Company and save its link. Then sign out, enter Blue Company, and open that saved link. The app must check ownership again instead of trusting that the link was previously valid. Hiding the item from Blue Company’s menu is helpful for clarity, but it does not protect the information if the saved link still opens it.

Viewing is only half of the test. For every kind of customer item, try the normal actions your app offers: create, rename, edit, archive, delete, upload, download, export, invite a team member, send a message, and change settings. Confirm first that the action works for the account that owns the item. Then switch accounts and confirm the other customer cannot find the item or complete the action through a saved link, a bulk action, or an old notification.

The final ownership decision must happen in the protected part of the app that reads, saves, sends, or deletes information. Developers call this a server-side check. A hidden button alone is not protection because the screen is only one way to ask the app to perform an action. The protected part must identify the signed-in account, find the item’s recorded owner, compare the two, and refuse safely when they do not match. Passwords, payment keys, and powerful access codes should also remain in that protected part.

Keep the two test accounts after the app is available to customers. Repeat the checks whenever you add or change anything that displays, searches, summarizes, copies, imports, exports, sends, or deletes customer information. Pay particular attention to AI-generated summaries, shared workspaces, staff tools, file storage, email messages, payment records, and reporting services. Write down the date, the feature tested, the two accounts used, and the result. This creates a simple history of what you actually verified.

VibeCodeWall can add an outside view by checking the public app from the outside and watching for important changes over time. It does not see your private code, and it cannot sign in as your test customers unless you perform those checks yourself. Use its observations as a reason to review unexpected public pages, exposed responses, or changed behavior. Continue using the two-account test because it confirms the rules that are specific to your customers, teams, shared items, and approved staff access.