A login screen is not the same as deciding what each person can open
If your app only checks whether someone signed in, people may reach pages or actions they should never use. The easiest test is to compare two real accounts with different access.
before you start
Someone being able to sign in does not automatically mean they should see every page or use every action. Test with two real accounts and repeat the check after changes.
What this means in simple words
in plain words
A sign-in screen answers who the person is. It does not answer what that person is allowed to see, open, change, or delete.
Many first-time app creators assume that once a person has signed in, the hard part is done. But there are really two separate questions. First: is this person a real user of the app? Second: what should this person be allowed to do now? The technical name for the first question is authentication. The technical name for the second question is authorization. Your app needs both.
This matters because a clean sign-in flow can create false confidence. A person may sign in correctly and still be blocked from staff pages, billing tools, exports, or other people’s records. If your app only checks sign-in and does not check access rules on each sensitive page and action, the wrong person may still get in. Developers call this access control, which simply means the rules that decide who can reach what.
For a beginner, the easiest way to think about it is this: a hotel key proves you are a guest, but it should not open every room in the building. Your app works the same way. Signing in should identify the person, but every important screen and action still needs its own rule about who is allowed to use it.
- ▸Signing in proves identity, not permission.
- ▸Each page and action needs its own access rule.
- ▸A person can be a valid user and still be blocked from many areas.
- ▸Developers call these permission rules access control.
common risk
You build an admin page and hide its menu link for normal users. A customer cannot see the button, so you assume the page is protected. But if that customer opens the page address directly, the page still loads because the app only checked whether the person was signed in.
what to do now
List your sensitive areas now: admin pages, billing, exports, account settings, team tools, and any screen that shows private data. Next to each one, write who should be allowed and who should be blocked.
ask your AI
Audit my app for the difference between signing in and permission checks. Make a table of every page, data view, and action in the app. For each item, list which user types should be allowed, which should be blocked, where the rule is checked, and whether the rule is enforced again on the server before data is shown or changed. Then suggest exact fixes for any place that only checks whether the user is signed in.
Why it matters before real people use your app
in plain words
If your app gets this wrong, a normal user may see private information or use actions meant only for someone else.
Problems here are common because the app can look correct during a happy-path demo. A normal user signs in, does normal tasks, and nothing looks broken. The issue appears when someone tries a page address from an old bookmark, refreshes a page after navigation changed, or opens a screen that was only hidden in the visible interface. If the deeper rule is missing, the app may still reveal information or allow a change it should refuse.
The place where the final decision must happen is the computer system that sends or saves real data. In simple words, that is the part of your app that should not trust what the person’s browser says. Developers call that server-side enforcement. This means the app checks the rule again before returning private data or accepting a change. A hidden button is useful for a cleaner experience, but it is not enough for safety.
This is especially important when you build fast with AI tools. New pages, new account types, and copied patterns can appear quickly. A generated screen may look polished while missing a real rule underneath. That is why you should treat permission checks as a product requirement, not as later cleanup.
- ▸A nice-looking screen can still have weak access rules.
- ▸Hidden navigation is not the same as a real block.
- ▸Important decisions must be checked again where data is sent or saved.
- ▸Fast AI-built changes make repeat testing more important.
common risk
Your app hides the Export button for regular users. But the export action still runs if the page sends the same request in the background after a saved bookmark is opened. The person never saw the button, but the app still did the restricted job.
what to do now
For every sensitive feature, confirm there is a real deny result when the wrong account tries it. The app should not just hide the option. It should refuse the page, refuse the data, and refuse the change.
ask your AI
Review my app for places where the visible interface hides an option but the real rule may be missing. Check all sensitive pages and actions and confirm there is a second permission check before private data is returned or any change is saved. Show me any page address or action that relies only on browser-side checks, and generate the code changes needed to enforce the rule on the server as well.
How to test with two accounts
in plain words
The simplest real-world test is to compare one ordinary account with one higher-access account and try the same pages and actions with both.
You do not need advanced tools to catch many access mistakes. Create two real accounts. One should represent the everyday user, such as a customer or member. The other should represent a person with extra access, such as a manager or admin. Then make a short list of pages and actions to test: view records, edit records, delete records, invite others, open reports, change plans, and open staff-only areas.
Now run the same test with both accounts. First, use the app normally by clicking menus and buttons. Then try direct page addresses, page refreshes, browser history, and bookmarks. If one account is blocked in the menu but still reaches the page by typing the address, your rule is incomplete. If the blocked account can still see data for another person, your rule is failing at a more serious level.
Keep the expected results simple and written down. For each item, mark should allow or should block for account A and account B. This makes it much easier to spot drift after updates. It also gives your AI builder a clear target when you ask it to fix access problems.
- ▸Use one normal account and one higher-access account.
- ▸Test both by clicking and by opening page addresses directly.
- ▸Check viewing, editing, deleting, exporting, inviting, and admin tools.
- ▸Write expected allow or block results before you test.
common risk
A normal account is blocked from the team settings menu. But after the user refreshes an old team settings page saved in the browser, the screen loads and shows member emails because the rule was not checked again when the page loaded.
what to do now
Create your two accounts today and run a full pass on your most sensitive flows. Save the results as a repeatable checklist for future published changes.
ask your AI
Create a two-account access test plan for my app. Assume Account A is a normal user and Account B has higher access. List every sensitive page and action, expected results for each account, and exact manual steps including clicking through the app, opening page addresses directly, refreshing pages, and revisiting through browser history. Then add any automated tests you can create from this plan.
What to keep checking over time
in plain words
Access rules can break later, so this should become a repeated outside check, not a one-time task.
Even if your app works today, changes can reopen old mistakes. New pricing plans, team roles, copied screens, and rushed edits can all weaken access rules. That is why the same two-account test should run whenever you change roles, private pages, account settings, staff tools, or anything tied to user permissions. A short routine is enough if you do it consistently.
You should also think about what the public version of your app reveals before anyone signs in. VibeCodeWall helps by checking the public app from the outside and watching for important changes over time. It does not see your private code. Its value is in spotting public exposure patterns and reminding you to recheck important areas as your app changes.
The ongoing goal is simple: the public side of the app should reveal only harmless information, and every important action should be allowed only for the right person every time. When something changes, rerun the test instead of assuming the old rule still works.
- ▸Repeat the test after role, plan, or feature changes.
- ▸Check what the public app reveals before sign-in.
- ▸Use outside checks to watch for important changes over time.
- ▸Do not assume old permission rules still hold after updates.
common risk
A new feature is added for managers only. Weeks later, a copied settings page accidentally gives normal users the same access because the old test was never rerun after the update.
what to do now
Add the two-account check to every time you prepare to publish. If a feature touches private data or powerful actions, it does not ship until both accounts behave exactly as expected.
ask your AI
Turn my access checks into a repeatable routine for publishing changes. Create a checklist for every future update that includes two-account testing, direct page address testing, refresh testing, and review of any new page or action that shows private data or changes important settings. Also flag any public browser-delivered file or public key that has more permission than necessary and suggest safer limits.
Quick checklist
- 01Create two real accounts with different access, such as a normal customer and a manager.
- 02Write down which pages, data, and actions each account should be allowed to use.
- 03Test by clicking through the app, then by opening page addresses directly and refreshing them.
- 04Make sure hidden buttons are not the only protection and that the server blocks disallowed actions too.
- 05Review what your app shows to the public before sign-in and keep powerful keys out of browser-delivered files.
- 06Repeat the same checks after changes to roles, plans, new features, or published updates.
FAQ
If someone can sign in, does that mean they should be able to open the page?
No. Signing in only proves who the person is. Your app still needs a separate rule for what that person may open, see, or change.
Why are two accounts enough for a basic test?
Because they make differences visible quickly. When one account should be blocked and the other should be allowed, mistakes become much easier to spot.
Is hiding a button good enough?
No. Hiding a button improves the screen, but the app must still refuse the page or action when the wrong account tries it.
What should I recheck after an update?
Recheck any page, data view, or action tied to user permissions, especially admin tools, billing, exports, team settings, and anything new added by your AI builder.