Sep 13, 2025·7 min
Permissions-aware navigation menus that still enforce access
Permissions-aware navigation menus improve clarity, but security must live on the backend. See simple patterns for roles, policies, and safe UI hiding.
Permissions-aware navigation menus improve clarity, but security must live on the backend. See simple patterns for roles, policies, and safe UI hiding.
When people say “hide the button,” they usually mean one of two things: reduce clutter for users who can’t use a feature, or stop misuse. Only the first goal is realistic on the frontend.
Permission-aware navigation menus are mainly a UX tool. They help someone open the app and immediately see what they can do, without running into “Access denied” screens every other click. They also cut support load by preventing confusion like “Where do I approve invoices?” or “Why does this page error out?”
Hiding UI isn’t security. It’s clarity.
Even a curious coworker can still:
So the real problem permission-aware menus solve is honest guidance. They keep the interface aligned with the user’s job, role, and context, while making it obvious when something isn’t available.
A good end state looks like this:
Example: in a small CRM, a Sales Rep should see Leads and Tasks, but not User Management. If they paste the user management URL anyway, the page should fail closed, and the server should still block any attempt to list users or change roles.
Visibility is what the interface chooses to show. Authorization is what the system will actually allow when a request hits the server.
Permission-aware menus reduce confusion. If someone will never be allowed to see Billing or Admin, hiding those items keeps the app clean and lowers support tickets. But hiding a button is not a lock. People can still try the underlying endpoint using dev tools, an old bookmark, or a copied request.
A practical rule: decide what experience you want, then enforce the rule on the backend no matter what the UI does.
When you’re deciding how to present an action, three patterns cover most cases:
“You can view but not edit” is common and worth designing explicitly. Treat it as two permissions: one for reading data and one for changing it. In the menu, you might show Customer details to everyone who can read, but only show Edit customer to those with write access. On the page, render fields read-only and gate edit controls, while still allowing the page to load.
Most importantly, the backend decides the final outcome. Even if the UI hides every admin action, the server still needs to check permissions on every sensitive request and return a clear “not allowed” response when someone tries.
The fastest way to ship permission-aware menus is to start with a model your team can explain in one sentence. If you can’t explain it, you won’t keep it correct.
Use roles for grouping, not for meaning. Admin and Support are useful buckets. But when roles start multiplying (Admin-West-Coast-ReadOnly), the UI becomes a maze and the backend becomes guesswork.
Prefer permissions as the source of truth for what someone can do. Keep them small and action-based, like invoice.create or customer.export. This scales better than role sprawl because new features usually add new actions, not new job titles.
Then add policies (rules) for context. This is where you handle “can edit only your own record” or “can approve invoices only under $5,000.” Policies prevent you from creating dozens of near-duplicate permissions that differ only by a condition.
A maintainable layering looks like this:
Naming matters more than people expect. If your UI says Export Customers but the API uses download_all_clients_v2, you’ll eventually hide the wrong thing or block the right thing. Keep names human, consistent, and shared between frontend and backend:
noun.verb (or resource.action) consistentlyExample: in a CRM, a Sales role might include lead.create and lead.update, but a policy limits updates to leads the user owns. That keeps your menu clear while your backend stays strict.
Permission-aware menus feel good because they reduce clutter and prevent accidental clicks. But they only help when the backend stays in charge. Think of the UI as a hint, and the server as the judge.
Start by writing down what you’re protecting. Not pages, but actions. View customer list is different from export customers and delete customer. This is the backbone of permission-aware navigation menus that don’t turn into security theater.
canEditCustomers, canDeleteCustomers, canExport, or a compact list of permission strings. Keep it minimal.A small but important rule: never trust client-provided role or permission flags. The UI can hide buttons based on capabilities, but the API must still reject unauthorized requests.
Permission-aware navigation menus should help people find what they can do, not pretend to enforce security. The frontend is a guide rail. The backend is the lock.
Instead of scattering permission checks across every button, define your navigation from one config that includes the required permission for each item, then render from that config. This keeps the rules readable and avoids forgotten checks in odd corners of the UI.
A simple pattern looks like this:
const menu = [
{ label: "Contacts", path: "/contacts", requires: "contacts.read" },
{ label: "Export", action: "contacts.export", requires: "contacts.export" },
{ label: "Admin", path: "/admin", requires: "admin.access" },
];
const visibleMenu = menu.filter(item => userPerms.includes(item.requires));
Prefer hiding whole sections (like Admin) over sprinkling checks on every single admin page link. That’s fewer places to get wrong.
Hide items when the user will never be allowed to use them. Disable items when the user could use them, but the current context is missing.
Example: Delete contact should be disabled until a contact is selected. Same permission, just not enough context yet. When you disable, add a short “why” message near the control (tooltip, helper text, or inline note): Select a contact to delete.
A rule set that holds up:
Hiding menu items helps people focus, but it doesn’t protect anything. The backend must be the final judge because requests can be replayed, edited, or triggered outside your UI.
A good rule: every action that changes data needs one authorization check, in one place, that every request passes through. That can be middleware, a handler wrapper, or a small policy layer you call at the start of each endpoint. Pick one approach and stick to it, or you’ll miss paths.
Keep authorization separate from input validation. First decide, “is this user allowed to do this?”, then validate the payload. If you validate first, you can leak details (like which record IDs exist) to someone who shouldn’t even know the action is possible.
A pattern that scales:
Can(user, "invoice.delete", invoice)).Use status codes that help both your frontend and your logs:
401 Unauthorized when the caller is not logged in.403 Forbidden when logged in but not allowed.Be careful with 404 Not Found as a disguise. It can be useful to avoid revealing a resource exists, but if you mix it randomly, debugging gets painful. Choose a consistent rule per resource type.
Make sure the same authorization runs whether the action came from a button click, a mobile app, a script, or a direct API call.
Finally, log denied attempts for debugging and audits, but keep logs safe. Record who, what action, and which high-level resource type. Avoid sensitive fields, full payloads, or secrets.
Most permission bugs show up when users do something your menu never expected. That’s why permission-aware navigation menus are useful, but only if you also design for the paths that bypass them.
If the menu hides Billing for a role, a user can still paste a saved URL or open it from browser history. Treat every page load like a fresh request: fetch the current user’s permissions, and have the screen itself refuse to load protected data when the permission is missing. A friendly “You don’t have access” message is fine, but the real protection is that the backend returns nothing.
Anyone can call your API from dev tools, a script, or another client. So check permissions on every endpoint, not just admin screens. The easy-to-miss risk is bulk actions: a single /items/bulk-update can accidentally let a non-admin change fields they never see in the UI.
Roles can also change mid-session. If an admin removes a permission, the user might still have an old token or cached menu state. Use short-lived tokens or a server-side permission lookup, and handle 401/403 responses by refreshing permissions and updating the UI.
Shared devices create another trap: cached menu state can leak across accounts. Store menu visibility keyed by user ID, or avoid persisting it at all.
Five tests worth running before release:
Imagine an internal CRM with three roles: Sales, Support, and Admin. Everyone signs in and the app shows a left menu, but the menu is only a convenience. The real safety is what the server allows.
Here’s a simple permission set that stays readable:
The UI starts by asking the backend for the current user’s allowed actions (often as a list of permission strings) plus basic context like user id and team. The menu is built from that. If you don’t have billing.view, you don’t see Billing. If you have leads.export, you see an Export button on the Leads screen. If you can only edit your own leads, the Edit button can still appear, but it should be disabled or show a clear message when the lead isn’t yours.
Now the important part: every action endpoint enforces the same rules.
Example: Sales can create leads and edit leads they own. Support can view tickets and assign tickets, but can’t touch billing. Admin can manage users and billing.
When someone tries to delete a lead, the backend checks:
leads.delete?lead.owner_id == user.id?Even if a Support user manually calls the delete endpoint, they get a forbidden response. The hidden menu item was never the protection. The backend decision was.
The biggest trap with permission-aware navigation menus is thinking you finished the job when the menu looks right. Hiding buttons reduces confusion, but it doesn’t reduce risk.
Mistakes that show up most often:
isAdmin flag for everything. It feels fast, then it spreads. Soon every exception becomes a special case and nobody can explain access rules.role, isAdmin, or permissions from the browser as truth. Derive identity and access from your own session or token, then look up roles and permissions server-side.A concrete example: you hide the Export leads menu item for non-managers. If the export endpoint doesn’t also check permissions, any user who guesses the request (or copies it from a coworker) can still download the file.
Before you ship permission-aware navigation menus, do one last pass focused on what users can actually do, not what they can see.
Walk through your app as each main role and try the same set of actions. Do it in the UI and also by calling the endpoint directly (or using browser dev tools) to make sure the server is the source of truth.
Checklist:
One practical way to spot gaps: pick one “dangerous” button (delete user, export CSV, change billing) and trace it end to end. The menu item should be hidden when appropriate, the API should reject unauthorized calls, and the UI should recover gracefully when it gets a 403.
Start small. You don’t need a perfect access matrix on day one. Pick the handful of actions that matter most (view, create, edit, delete, export, manage users), map them to the roles you already have, and move on. When a new feature lands, add only the new actions it introduces.
Before you build screens, do a quick planning pass that lists actions, not pages. A menu item like Invoices hides a lot of actions: view list, view details, create, refund, export. Writing those down first makes both the UI and the backend rules clearer, and it prevents the common mistake of gating a whole page while leaving a risky endpoint under-protected.
When you refactor access rules, treat it like any other risky change: keep a safety net. Snapshots let you compare behavior before and after. If a role suddenly loses access it needs, or gains access it shouldn’t have, rollback is faster than hot-fixing production while users are blocked.
A simple release routine helps teams move quickly without guessing:
If you’re building with a chat-based platform like Koder.ai (koder.ai), this same structure still applies: keep permissions and policies defined once, have the UI read capabilities from the server, and make backend checks non-optional in every handler.
Permission-aware menus mostly solve clarity, not security. They help users focus on what they can actually do, reduce dead-end clicks, and cut “why am I seeing this?” support questions.
Security still has to be enforced on the backend, because anyone can try deep links, old bookmarks, or direct API calls regardless of what the UI shows.
Hide when a feature should be effectively undiscoverable for a role and there’s no expected path for them to use it.
Disable when the user might have access but is missing context right now, like no record selected, invalid form state, or data still loading. If you disable, add a short explanation so it doesn’t look broken.
Because visibility is not authorization. A user can paste a URL, reuse a bookmarked admin screen, or call your API outside your UI.
Treat the UI as guidance. Treat the backend as the final decision-maker for every sensitive request.
Your server should return a small “capabilities” response after login or session refresh, based on server-side permission checks. The UI then renders menus and buttons from that.
Do not trust client-provided flags like isAdmin coming back from the browser; compute permissions from the authenticated identity on the server.
Start by inventorying actions, not pages. For each feature, separate things like read, create, update, delete, export, invite, and billing changes.
Then enforce each action in the backend handler (or middleware/wrapper) before doing any work. Wire the menu to the same permission names so UI and API stay aligned.
A practical default is: roles are buckets, permissions are the source of truth. Keep permissions small and action-based (for example, invoice.create), and attach them to roles.
If roles start multiplying to encode conditions (like region or ownership), move those conditions into policies instead of creating endless role variants.
Use policies for contextual rules like “can edit only your own record” or “can approve invoices under a limit.” That keeps your permission list stable while still expressing real-world constraints.
The backend should evaluate the policy using resource context (like owner ID or org ID), not assumptions from the UI.
Not always. Reads that expose sensitive data or bypass normal filtering should be gated too, such as exports, audit logs, salary data, admin user lists, or any endpoint that returns more than the UI normally shows.
A good baseline is: all writes must be checked, and sensitive reads must be checked as well.
Bulk endpoints are easy to miss because they can change many records or fields in one request. A user might be blocked in the UI but still hit /bulk-update directly.
Check permissions for the bulk action itself, and also validate which fields are allowed to be changed for that role, otherwise you can accidentally allow hidden fields to be edited.
Assume permissions can change while someone is logged in. When the API returns 401 or 403, the UI should handle it as a normal state: refresh capabilities, update the menu, and show a clear message.
Also avoid persisting menu visibility in a way that can leak across accounts on shared devices; if you cache it, key it by user identity or don’t persist it at all.