A Login Does Not Decide What Each Person Can See
A working login is only the entrance. Test your app with two different accounts to make sure one customer cannot see another customer’s information or use staff-only tools.
before you start
Someone who enters your app should not automatically see every customer record, payment option, or staff tool.
Entering the app is only the first check
in plain words
A login confirms who entered, but separate rules must decide what that person may see or change.
When someone creates an account, enters a password, and reaches the first screen, your app has answered only one question: who is this person? It has not yet decided whether that person may read a customer record, change an order, issue a refund, download a report, or manage another account. Those decisions need their own rules. Without them, every signed-in person may be treated as if they have the same rights.
Think of a building with a front door and several locked rooms. Showing an identity card may open the front door, but it does not provide a key to every room. The technical name is authentication when an app confirms who a person is. The technical name is authorization when the app decides what that confirmed person may see or do. Your app needs both decisions, and the second one must be repeated whenever important information or an important action is requested.
- ▸List what customers, staff members, and owners should each be allowed to use.
- ▸Treat viewing, editing, deleting, downloading, approving, and refunding as different permissions.
common risk
A customer signs in normally and can open staff settings because the app checked only whether somebody had entered a password.
what to do now
Write a simple table with each account type, its allowed pages, its allowed information, and its allowed actions.
ask your AI
Review my app after sign-in. For every page, customer record, file, payment action, and staff tool, check whether the specific signed-in person is allowed to view or use it. Do not rely on hidden buttons. Explain each rule and each change in language a complete beginner can understand.
Test with two different people
in plain words
Two accounts can reveal information leaks that your owner account may hide.
Testing only with your own account is not enough. An owner usually has broad permission, so seeing every order or setting may be correct for you while being wrong for a customer. Create two accounts that represent different people. You could use two customer accounts, each with a different sample order, or one customer account and one staff account. Do not use real customer information, real payment details, or a password that you use elsewhere.
Give each account a clearly different name and harmless sample information. Before testing, write what each person should and should not see. The technical name is a role when an account represents a job or position, such as customer, support worker, or owner. Test one role at a time. Sign out completely between tests, or use separate copies of the program that opens websites. That program is called a browser, and separate browser profiles help prevent one account from being confused with the other.
- ▸Use obvious sample names, such as Test Customer One and Test Customer Two.
- ▸Give each account a different sample order, booking, message, or uploaded file.
common risk
Everything looks correct in the owner account, but the first customer account receives the second customer’s order list.
what to do now
Create two non-real accounts today, add one recognizable sample item to each, and record the expected result for every check.
ask your AI
Help me prepare two safe test accounts with different permissions and clearly different sample records. Create a step-by-step table showing what each account should be allowed and refused when viewing, editing, deleting, downloading, approving, or refunding.
Try saved page addresses too
in plain words
A hidden button does not protect the page or information behind it.
Removing a button from a customer’s screen can make the app easier to understand, but it does not prove that the hidden page is blocked. Someone might still have its address in a bookmark, an old message, or an open tab. The app must check the person again when that address opens and when information is requested. If the person is not allowed, the app should stop, avoid sending the information, and show a clear message.
Copy the address of a restricted page while using the account that should have access. Then sign in with the account that should be refused, paste the address, open it, and refresh it. The protected computer that receives requests and decides what information to send is called a server. Developers call this a server-side permission check when that protected computer makes the decision. This check matters because visitors cannot safely be trusted to enforce rules using only what appears or disappears on their screens.
- ▸Open restricted addresses directly instead of testing only visible menus.
- ▸Refresh the page and return from an old tab to confirm that the refusal remains in place.
common risk
The Manage People button is hidden, but a customer with the saved page address can still open it and change somebody else’s account.
what to do now
Use the account with fewer permissions to test the direct address of every staff, owner, billing, and account-management page.
ask your AI
Find every page that is restricted only because a menu item or button is hidden. Add a server-side permission check before the page loads or sends information. When the signed-in person is not allowed, send no restricted information and show a clear refusal message.
Check every customer item separately
in plain words
A customer may use an order screen without being allowed to receive another customer’s order.
Whole-page rules are not enough. Two customers may both be allowed to open order history, messages, bookings, or uploaded files, but each person should receive only their own items. Before the app displays, changes, deletes, downloads, or shares an item, it should compare the signed-in person with the person connected to that item. The same rule should cover lists, search results, detail screens, reports, addresses, and files.
A stored piece of information, such as one order or booking, is often called a record. Developers call the comparison an ownership check when the app confirms that the current person owns a record or has a valid work reason to handle it. Use the two accounts to test every way a record can be reached. Staff members may need wider access, but their access should still match their duties instead of giving every worker permission to see all customer information.
- ▸Check lists, searches, details, downloads, reports, editing, and deletion.
- ▸Confirm that changing an item follows the same ownership rule as viewing it.
common risk
A customer sees only their own dashboard, but opening a saved order address displays another customer’s name, delivery address, and purchase details.
what to do now
Choose one important item type, such as orders or bookings, and test every way both accounts can view or change it.
ask your AI
For every customer record in my app, make the server confirm that the signed-in person owns it or has a clearly defined work reason before viewing, editing, deleting, downloading, sharing, or including it in search results. Keep staff permissions limited to their stated duties.
Repeat the checks after every important change
in plain words
A new payment, report, or account feature can accidentally remove a rule that worked before.
Permission mistakes can return during ordinary improvements. A new report, a faster search, a payment option, or a change to account settings may forget one of the existing checks. Keep both test accounts available and repeat the same short routine whenever you publish a change involving accounts, customer information, files, payments, or staff tools. Test both what each person should receive and what each person should be refused.
Include the app’s most sensitive objects in this routine. Passwords, payment keys, and access codes that can open customer information or spend money must stay in the protected part of the app that visitors cannot download. VibeCodeWall checks the public app from the outside and watches for important changes over time. It does not need to see private code. This outside view supports ongoing checking, but you should still run the two-account test because your expected permissions depend on how your business works.
- ▸Run the same checks before and after publishing a relevant change.
- ▸Remove unused test accounts and replace sample information when it is no longer helpful.
common risk
A new download feature works for the owner but forgets to check who owns each order, so a customer receives a file containing other customers’ information.
what to do now
Save the two-account test as a required routine for every change involving people, information, money, files, or staff work.
ask your AI
Create a repeatable pre-publication and post-publication checklist for my app. Test two accounts after changes involving sign-in, customer records, files, payments, downloads, or staff tools. Also verify that passwords, payment keys, and codes that open customer information remain only in the protected server-side part of the app and never appear in files visitors can download.
Quick checklist
- 01Create two test accounts that represent different people.
- 02Give each account clearly labeled sample information.
- 03Write down what each account should be able to see and do.
- 04Sign out fully before changing from one account to the other.
- 05Try opening a page address copied from the other account.
- 06Check viewing, editing, deleting, downloading, approving, and refunding separately.
- 07Confirm that one customer cannot receive another customer’s information.
- 08Keep passwords, payment keys, and data-opening access codes in the protected part of the app that visitors cannot download.
- 09Repeat the two-account test after changes to accounts, payments, files, or staff tools.
FAQ
Does a login screen protect customer information by itself?
No. It identifies who entered, but every page, item, and action still needs a rule deciding whether that person is allowed to use it.
Why should I use two test accounts?
An owner account can see almost everything and hide mistakes. Two accounts show whether different people actually receive different information and permissions.
Is hiding a button enough?
No. The app must refuse the page and its information even when somebody opens a saved address directly.
What should I test first?
Start with customer details, orders, bookings, staff settings, downloads, payments, refunds, and anything that changes or deletes information.