1. Hiding is UX; authorization is the control

Showing users only the menus, actions, and pages their privileges permit is good design — it reduces confusion and the temptation to probe. But feature hiding is a usability layer, not a security boundary: an attacker ignores your UI and calls the endpoint directly. The hidden button must sit on top of real server-side authorization, not in place of it.

2. One source of truth for both

The right architecture drives the UI from the same permission model that guards the endpoints. A user without the permit does not see the action and cannot invoke it, because both consult the same authorization decision. The interface and the enforcement never drift apart, and there is no “hidden but reachable” gap to exploit.

3. How B5 Secure handles it

B5 Secure drives feature hiding from its permission-based authorization, so menus, actions, and pages reflect privilege at the interface while the same permits enforce access at the endpoint. The UI is honest about what a user can do because it is reading the control that decides it.