As soon as an application has more than one kind of user, such as a customer, a staff member and an owner, you need to define exactly what each is allowed to do.
A simple model
- List the actions (view orders, edit prices, cancel a booking, see reports).
- List the roles (customer, staff, manager, administrator).
- Decide which roles may perform which actions, and on whose data: a staff member may edit their own calendar but not a colleague’s, for example.
Where checks belong
On the server, every time. If permissions are only enforced by hiding menu items, anyone who guesses or copies a request can bypass them. The server must verify who is asking and whether they may do this to this record.
Common mistakes
- Checking the role but not the ownership, so users can read each other’s records by changing a number in the address.
- Spreading permission checks across hundreds of places instead of one consistent layer.
- Hard-coding rules that later need to vary by customer.
- No record of who changed what, which makes disputes hard to settle.
Start with few roles and make them clear. A permission system that is too clever is hard to reason about, and in security, what you cannot reason about you cannot trust.