A Hidden Admin Link Does Not Keep People Out
Removing an admin link only hides it from the menu. Your app must also check who the person is before showing customer information or accepting an owner-only action.
before you start
Removing a door sign does not lock the door. Your app must check each person before opening staff pages or accepting important changes.
Hiding the link does not close the page
in plain words
Someone may still open a staff page even when its link is missing from the menu.
Imagine that your app has a page where you change prices, view every customer, or manage orders. Removing its link from the menu makes the page harder to notice, but the page may still exist at the same web address. A person could have saved that address, received it from someone else, found it in their browsing history, or followed another button you forgot to remove. If the app opens the page without checking the person, hiding the link has provided appearance, not protection.
The app needs to make a decision before it shows the page: is this signed-in person allowed to be here? It must make the same kind of decision before showing customer information or accepting a change. Developers call this authorization. The plain idea is simply that recognizing a person is different from deciding what that person may do. Signing in tells the app which account is present; a separate rule decides whether that account belongs to an owner, a staff member, or a customer.
- ▸Hide staff links when they are not useful to the current person.
- ▸Also refuse to open the page when that person is not allowed.
common risk
A customer opens an old bookmark for the owner dashboard. The menu has no admin link, but the page still displays every order because no permission decision happens.
what to do now
Open the published app in a signed-out window and then with a normal customer account. Enter every known staff-page address directly and confirm that the app refuses to show the page or its information.
ask your AI
Review my entire app for pages intended only for the owner or staff. For every one, require a signed-in account and check the person's current role on the server before sending the page or any protected information. Refuse signed-out customers and accounts without permission. Hide unnecessary menu links too, but do not treat hidden links as protection.
Decide what each kind of account may do
in plain words
Write down the allowed jobs for owners, staff, and customers before asking the app to enforce them.
Start with account types that match the people who use your business. You may need only owner, staff member, and customer. Next, list concrete tasks: changing prices, issuing refunds, reading all customer information, inviting staff, exporting orders, and editing payment settings. Decide which account type needs each task for real work. Avoid making everyone an administrator merely because that was convenient while building the first version. Broad power can turn one mistaken click or one stolen password into a much larger problem.
Give each account only the abilities required for its current job. Developers call this least privilege. For example, a staff member who packs orders may need customer names and delivery addresses for assigned orders, but may not need payment settings, staff invitations, refunds, or a download of the full customer list. Treat viewing information and changing information as different abilities. Also separate ordinary order updates from actions involving money. Clear, narrow rules are easier for you, your AI builder, and future staff to understand and test.
- ▸Make a short list connecting each account type to its allowed tasks.
- ▸Separate reading customer information, changing settings, and moving money.
common risk
Every employee receives owner powers so they can edit products. As a result, people who only prepare orders can also issue refunds, invite new staff, and download all customer information.
what to do now
Write one sentence for each account type stating what it may view, create, change, and delete. Remove any ability that is not required for a current job.
ask your AI
Create and enforce three roles in my app: owner, staff, and customer. Owners may manage staff, payment settings, refunds, prices, and all customer records. Staff may view and update only orders assigned to their work and may not manage staff, payment settings, refunds, or full customer exports. Customers may view and change only their own account and orders. Show me the resulting permission list before making changes.
Check permission where the app does the work
in plain words
The important decision must happen in the protected part of the app, not only on the visitor's screen.
The visitor uses a browser, which is the program that displays your app, such as Chrome or Safari. Your app sends files to that program so it can draw pages and buttons. Anything enforced only by those delivered files is under the visitor's control. A hidden refund button may disappear from the screen, yet the app could still accept the underlying request if no second check exists. That is why changing what someone sees is useful for clarity but cannot be the final safety decision.
The protected part of the app runs on another computer that receives requests and performs work. Developers call that computer and its software the server. Before it returns a customer list, changes a price, creates a refund, or invites a staff member, it should identify the signed-in account, read that account's current role, and confirm the requested task is allowed. Developers call this server-side access checking. The check must happen before any information is returned or any change begins, and a failed check should produce a calm refusal without revealing protected details.
- ▸Check permission before returning protected records or reports.
- ▸Check permission before creating, changing, or deleting anything important.
common risk
The refund button is hidden from staff members, but the protected part of the app processes their refund request because it never checks their current role.
what to do now
Ask your AI builder to identify every place where the app reads protected information or performs an owner-only task. Require a permission decision at the beginning of each one.
ask your AI
Find every server function that returns all-customer information, changes prices or settings, manages staff, changes orders, or affects payments. At the start of each function, identify the signed-in account, load its current role from trusted stored data, and allow only the roles listed for that action. Stop immediately with a generic not-allowed response when the check fails, before reading protected records or making any change.
Protect the information behind every page
in plain words
Blocking a page is not enough when its customer information can still be requested separately.
A staff page may ask another part of the app for customer names, orders, messages, or reports. The page and the information request need their own checks because blocking one does not automatically block the other. A customer should receive only records belonging to that customer's account. A staff member should receive only records needed for assigned work. An owner may receive a wider view when the task requires it. The app should make these choices before collecting and returning the information, not after it has already sent everything to the visitor.
Customer and order records are often kept in an organized data store. The technical name is a database. Its password, a payment provider key, or an access code that can open customer information or spend money must stay in the protected part of the app. Do not put those items in files sent to visitors, because visitors can save and inspect those files. The server should use each password, payment key, or access code only for the narrow job that requires it. Changing a label or hiding a page cannot repair an information request that answers the wrong person.
- ▸Return only records that belong to the signed-in customer or the staff member's assigned work.
- ▸Keep database passwords, payment provider keys, and powerful access codes away from visitor downloads.
common risk
The owner page refuses a customer, but the separate request used to fill its table returns the complete customer list to anyone who is signed in.
what to do now
Test with two customer accounts. Confirm that each account can receive only its own information and that neither can receive staff reports, all-customer lists, or another customer's orders.
ask your AI
Review every place my app loads customers, orders, messages, reports, staff records, or payment information. Require a signed-in account and an allowed role before reading the records. Customers must receive only records linked to their own account, and staff must receive only records required for assigned work. Keep the database password, payment provider key, and any access code that can open customer information or spend money only on the server and out of all files sent to visitors.
Retest whenever the app changes
in plain words
Use the wrong kind of account during testing so a missed rule becomes visible.
Testing only with your owner account can hide mistakes because that account is supposed to reach almost everything. Create a normal test customer and, when relevant, a limited staff account. Use separate private browsing windows so the accounts do not mix. Try direct addresses for owner pages, customer lists, reports, settings, refunds, and staff management. Confirm that the wrong account cannot see the screen, receive the underlying information, or complete the final action. Also test while signed out and after changing an account's role.
Repeat the test whenever your AI builder adds a page, changes sign-in behavior, creates a report, or modifies orders, payments, staff, or customer information. Keep a short written list so the same checks happen every time. VibeCodeWall checks the public app from the outside and watches for important changes over time; it does not need to see your private code. That outside view can help you notice changes in what the public app exposes, while your account tests confirm that the app's internal permission rules still make the right decisions.
- ▸Test while signed out, as a customer, and as limited staff.
- ▸Repeat the tests after every important change and after changing someone's role.
common risk
An AI builder adds a new sales report that works for the owner. Nobody retests with a customer account, so the missing permission check remains unnoticed.
what to do now
Save a repeatable test list and run it before publishing any change involving sign-in, account roles, customer information, payments, orders, staff, or owner pages.
ask your AI
Create automated tests for my app using signed-out, customer, limited-staff, and owner accounts. Verify that direct page addresses and server requests are refused when the account lacks permission. Cover owner pages, all-customer information, reports, settings, staff management, refunds, payment changes, and records belonging to another customer. Also verify that changing an account from staff to customer removes its former abilities immediately.
Quick checklist
- 01List every page and action intended only for the owner or staff.
- 02Decide whether the owner, staff, customers, or nobody else may use each item.
- 03Require people to sign in before opening restricted pages.
- 04Check each person's permission again before showing protected information.
- 05Check permission again before changing orders, payments, staff, or settings.
- 06Test direct page addresses while signed out and while using a customer account.
- 07Confirm that customers receive only their own records.
- 08Keep the database password, payment provider key, and powerful access codes away from files sent to visitors.
- 09Repeat the checks whenever your AI builder adds or changes an important feature.
- 10Use VibeCodeWall to check the public app from the outside and watch for important changes over time.
FAQ
Is hiding an admin link useful at all?
Yes. It keeps the screen simple and avoids confusing customers. It does not protect the page or its actions, so the app must still check each person's permission.
Does signing in make someone an administrator?
No. Signing in identifies the account. The app must separately decide whether that account is an owner, a staff member, or a customer and which tasks it may perform.
Where should the permission decision happen?
It should happen where the app reads protected information or performs the requested change. Developers call that protected part the server. A screen check can improve the experience, but it cannot be the only check.
What should the app show after refusing someone?
Show a simple sign-in or not-allowed message. Do not include customer information, internal settings, or clues about whether a protected record exists.