A Login Screen Does Not Decide What Each Person May Do
A working login screen is only the first step. Compare two test accounts to find out whether one person can view or change another person’s information.
before you start
Getting into an app should not give everyone the same power. Two test accounts can reveal whether each person stays within the limits you intended.
Know the two questions your app must answer
in plain words
Your app must identify the person who entered and separately decide what that person is allowed to see or change.
Imagine an appointment app used by customers, employees, and the business owner. A customer should see their own appointments. An employee might see appointments assigned to them. The owner may need the entire calendar. All three people can use the same login screen, but they should not receive the same view or the same powers after entering. The app must make a separate decision for every customer record, file, report, refund, and account setting it shows or changes.
The first question is, “Which account entered?” The technical name is authentication. A password, one-time access code, or sign-in link can help the app answer that question. The second question is, “What may this account do here?” The technical name is authorization. A successful answer to the first question does not answer the second. Your app needs both checks. It should decide whether the current account may view or change the specific information involved each time an important request is made.
- ▸List every kind of user, such as customer, employee, manager, and owner.
- ▸For each kind, write what they may view, create, change, download, delete, or manage.
common risk
An employee signs in correctly but can open a customer list that was meant only for the business owner.
what to do now
Create a simple table with one row for each type of user and one column for each important page or action. Mark what should be allowed and refused.
ask your AI
Review my app and make a permission table for every type of user. Include pages, customer records, files, reports, account settings, payments, refunds, downloads, edits, and deletions. For each item, state who should be allowed, who should be refused, and where the app currently checks that decision. Do not treat a hidden button as sufficient protection.
Compare two accounts using harmless sample information
in plain words
Two separate test accounts let you see whether one person can accidentally reach information belonging to another.
Create two accounts with obvious names, such as Test Ana and Test Bruno. Give them different fictional appointments, orders, profile notes, or project names. Do not enter real customer information, real payment details, or a password that you use elsewhere. Open one account in your normal browser window and the other in a separate browser profile or private window. Keep the account name visible if possible so that you always know which person you are testing.
Repeat the same ordinary journey with both accounts. Open the home screen, profile, lists, details, files, and forms that save changes. Use the app’s normal search, notifications, shared pages, and copied page addresses. Record what you expected and what actually happened. You are not trying to break into the app. You are checking whether Test Bruno can reach Test Ana’s sample information through features a normal user already has. If that happens, stop using the affected feature with real information until it is corrected and tested again.
- ▸Use visibly different names and sample records so that a mistake stands out.
- ▸Keep a short list with the task, expected result, and actual result for both accounts.
common risk
Both accounts can open the same order details even though each person should see only their own orders.
what to do now
Test one complete user journey with both accounts, and then repeat the test on the page containing the most sensitive customer information.
ask your AI
Help me set up Test Ana and Test Bruno with separate fictional records. Create a step-by-step test covering the home screen, profile, lists, detail pages, search, notifications, copied page addresses, forms, files, downloads, edits, and deletions. For every step, state what Ana should see, what Bruno should see, and what evidence I should record.
Check saved changes as well as visible buttons
in plain words
A missing button does not prove that the app will refuse an action that the person is not allowed to perform.
A screen can look correct while the underlying protection is missing. Test whether each account can open a record, save a form, upload a file, download a document, change an address, cancel an order, issue a refund, or remove information. After an action should be refused, refresh the page and confirm that nothing changed. A clear refusal message is useful, but the saved result matters most. Hiding a manager button makes the screen less confusing; it does not by itself stop an unwanted change.
The app should check the person and the specific item again in the part that receives the request and reads or saves information. Developers call this a server-side authorization check. A server is the computer system that stores information or performs work away from the visitor’s browser. Ask your AI builder to place the decision there, not only in files delivered to the browser. Passwords, payment keys, and powerful access codes must also remain in that protected part because visitors can inspect files their browsers receive.
- ▸Test viewing, creating, editing, uploading, downloading, refunding, and deleting wherever those actions exist.
- ▸After every refused action, confirm that no customer information or saved setting changed.
common risk
A customer cannot see an Edit button, but the app still accepts a change to another customer’s delivery address.
what to do now
For each important action, confirm that the app checks both the signed-in account and the owner or permitted group for the exact record involved.
ask your AI
For every operation that reads or changes saved information, add a server-side check before the operation happens. Compare the signed-in account with the owner of the exact record and with the allowed user type. Refuse the operation when either check fails, return a clear message, and make sure no information changes. List every file you changed and give me a two-account test for each rule.
Repeat the comparison whenever the app changes
in plain words
A new page, user type, file feature, or shortcut can accidentally give someone more reach than you intended.
Keep the two test accounts and their fictional records so you can repeat the same comparison. Run it after adding a page, report, paid feature, team role, file area, notification, or new way to open an existing item. Add another test account when you introduce a genuinely different job, such as manager or helper. A feature that worked safely last month can behave differently after a later change, especially when a new screen reads the same saved customer information in a different way.
Make the expected result part of your regular publishing checklist. Save the date, app version, account used, task, expected result, and actual result. VibeCodeWall checks the public app from the outside and watches for important changes over time. That outside view can help identify public-facing changes, but it does not replace your comparison of signed-in accounts. Your own test confirms whether people using normal app features remain inside the boundaries you chose. Correct unexpected reach before adding real customer information or inviting more people.
- ▸Repeat the same recorded tasks after changes to users, pages, stored information, or important actions.
- ▸Review the expected results whenever you add a new kind of user or a new business responsibility.
common risk
A new report is absent from the customer menu, but a customer can still open it from a notification and see every customer’s name.
what to do now
Add the two-account comparison to the checklist you complete before sharing any important change with real users.
ask your AI
Create a repeatable pre-publishing test for every user type in my app. Use fictional information and cover pages, records, files, searches, notifications, copied page addresses, downloads, edits, payments, refunds, and deletions. Include expected and refused results, instructions for confirming that saved information did not change, and a place to record the date and result.
Quick checklist
- 01Create two clearly named test accounts.
- 02Give each account different fictional information.
- 03Write down what each kind of user should be allowed to do.
- 04Repeat the same tasks while using each account.
- 05Check viewing, creating, changing, downloading, and deleting.
- 06Test ordinary users separately from managers or owners.
- 07Confirm that refused actions do not change saved information.
- 08Repeat the test after every important app change.
FAQ
Do I need two real email addresses?
Not always. Use the separate test-account method supported by your sign-in system. The accounts must be clearly labeled and must not contain real customer information.
Is hiding a manager button enough?
No. It can make the screen clearer, but the app must also refuse the action before it reads or changes saved information.
What should I do if one account sees the other account’s information?
Stop using that feature with real information, ask your AI builder to add a check for the account and the specific record, and repeat every related test with both accounts.
Can VibeCodeWall perform the signed-in comparison?
VibeCodeWall checks the public app from the outside and watches for important changes over time. Use separate test accounts to confirm what signed-in people can see and do.