App roles: administrator, employee, customer

Most business apps have three kinds of people: the administrator who sets everything up, the employees who work in it every day, and the customers who only see their own orders or appointments. Each gets exactly what they need, and the rule is enforced on the server, not in the menu. Settle the roles before the first screen is drawn and the app comes out simpler and safer.

Three roles, three questions

For every role, answer three questions: what can they see, what can they change, and what can they delete. Here is an example for a business that takes appointments:

The table looks obvious, but everything is built on it: screens, menus, tests. Without it, permissions get added on the fly because someone asked, and a year later nobody is quite sure who can see what.

Administrators: few and well protected

Don't make everyone an admin to keep things simple. OWASP, the reference organization for application security, recommends least privilege: each user gets only the permissions they need to do their job. Two admin accounts are usually enough, one for the owner and one for whoever runs the app day to day.

We covered the admin panel itself, with two-step sign-in and an activity log, in our article on the admin panel.

Employees: permissions by task, not by person

This is where the nuance lives. The front desk sees everyone's appointments, a technician sees only their own. A business with two locations wants each team to see only its own. The accountant sees invoices but can't edit them.

A few rules that save a lot of arguing:

• Define permissions as tasks ("confirm bookings", "export invoices"), then group them into roles. When a new job comes along, you combine existing tasks instead of inventing a role from scratch.
• A new account sees nothing until it gets a role. OWASP calls this deny by default.
• When someone leaves, it takes one click. The account is deactivated and the history stays. Delete the person and you lose the record of what they did.
• Review permissions now and then. OWASP warns that over time permissions creep beyond what was originally designed.

Customers: they see only what is theirs

The customer role looks like the easy one. It's also where apps most often get it wrong.

Say a customer opens their booking and the page address ends in "booking/1043". What happens if they type 1044? If the server only checks that the person is logged in, and not that booking 1044 belongs to them, they see someone else's data: name, phone number, maybe the reason for the visit.

The problem has a name, broken object level authorization, and it sits at number one on OWASP's 2023 list of API security risks. The recommended fix: for every request that carries an ID, the server checks whether the logged-in user is allowed to perform that action on that specific record. Hard-to-guess IDs help, but they don't replace the check.

GDPR says the same thing from the data side. Article 5 requires data to be "limited to what is necessary" for its purpose, and Article 25 requires that by default only the data needed for each purpose is processed. A customer who sees only their own records is exactly that.

How to check before launch

You can ask whoever builds your app to run this test. It takes about half an hour:

1. Create a test account for each role.
2. Logged in as an employee, type the admin page addresses straight into the browser.
3. Logged in as customer A, try to open an order or booking that belongs to customer B by changing the number in the address.
4. Deactivate an account and check it can no longer do anything, including from the phone app where it may already be signed in.

All four should fail. OWASP recommends automating tests like these, so a change that breaks the checks never reaches your customers.

What drives the cost: how many roles you need, how fine-grained the permissions are (by location, by customer, by document type), and whether you want to edit roles yourself from the admin panel. See how we work on our App Dev services page.