Deciding Who Can Do What

Hiding is not securing

Removing a button from the interface stops the average user and stops nobody who looks. Every action must be checked on the server, regardless of what the interface shows.

The most common authorisation failure we find is an endpoint that assumes the user could not have reached it, because the button was hidden.

Roles first, permissions where needed

1. Start with a small number of roles reflecting real jobs
2. Attach permissions to roles rather than to individuals
3. Add individual overrides only where the business genuinely needs them
4. Keep the number of roles small enough that people understand them

Twenty roles with overlapping permissions is unmanageable. Five clear ones covers most businesses.

Record ownership too

Role-based permissions answer “can this user edit orders?” They do not answer “can this user edit this order?” Both questions need answering.

• Filter every list query by what the user may see
• Check ownership before allowing any single-record action
• Never trust an identifier in the request to determine access
• Test with two accounts trying to reach each other's records

Make it auditable

Who did what and when, for anything consequential. That is both a security control and the answer to most “how did this happen?” questions.

Include permission changes themselves in the audit trail — who granted whom what access is frequently the important question.

Keep it operationally simple

Frequently asked questions