Should I bother hiding menu items if it is not security?

Yes. Most inappropriate access is accidental rather than malicious, and an interface that only shows what a person actually works with is both safer and easier to use. It just cannot be the last line.

How do I test whether a restriction is real?

Sign in as the restricted role and request the resource without using the interface — the direct address, or the API call the page would have made. Real restrictions refuse both.

What about data that is on the page but visually truncated?

If it reached the browser, it is disclosed. Fields a role may not see must be excluded from the query, not styled out of view.

Knowledge · Architecture

Navigation Visibility Is Not Authorization

Removing a link from the sidebar changes what a user sees, not what they can do. Why interface visibility and backend permission must be enforced separately.

Is hiding a menu item the same as blocking access?

No. Hiding a menu item removes a path to a screen; it does not remove the screen, the route or the underlying data access. A user who types the address, replays a request or calls the API directly is unaffected by anything the interface chose not to render.

Key takeaways

Visibility is a usability decision. Authorization is a security decision.
Anything the browser decides, the browser can be made to un-decide.
Hiding is still worth doing — it prevents accidents, not attacks.
The same permission answer should drive the menu, the route and the API.
If only the menu enforces it, it is not enforced.

What each layer actually buys you

Menu visibility: a clean interface and fewer accidental clicks into places a person has no business being.
Route guards: a graceful refusal instead of a broken screen when someone follows a stale link.
API and database checks: the only layer that decides whether the data moves.

Hidden versus disabled

A disabled control still advertises that a capability exists and invites a request for it. Hiding it entirely is usually the better product decision, because the interface stops describing a system the user is not part of. Neither choice, however, changes the answer the server gives.

Deriving all three from one source

The failure mode is drift: the menu is updated when a permission changes and the API is not, or the reverse. The fix is a single declared contract that both the interface and the enforcement layers read, so a permission change is one edit rather than three that must be remembered.

Where URBLD fits

URBLD's permissions contract names three layers where a rule must be enforced — interface, route and API — and sets hidden-not-disabled as the interface convention. The interface reads its access answers from the same declared module and action definitions used by route guards, and the database applies its own row-level policies underneath both. Menu hiding in URBLD is presentation; it is never described as the control that prevents access.

Security at URBLD Workforce & Roles

Principles reinforced

This page rests on the following foundational ideas.

One Source of Truth

FAQ

Frequently Asked Questions

Straight answers about how URBLD runs the business end-to-end.

Related knowledge

Roles vs capabilities

Authentication vs authorization