Role-Based Access Control: Who Can See and Change What?

Role-based access control, or RBAC, assigns permissions through roles such as staff, manager, client, and administrator. For a business app, role alone is often not enough. A client may view their own projects but not another client’s projects, and an employee may edit assigned work without having permission to export every record. “Everyone is an admin” is a convenient setup until someone clicks the very interesting delete button.

Describe access as role, record, and action

Begin with the work people need to do, not a list of convenient account types. For each action, identify which records the person may use and whether the permission changes with the record’s state. A manager might approve a draft but should not silently alter a previously accepted client decision.

Example: a copied project link

A client copies a project URL and sends it to a colleague at another company. The second person may already have an account in the same app, but that does not make the project theirs. The server must verify access to the requested record. The same rule should apply to attachments, search results, exports, and background jobs that use that record.

OWASP recommends denying access by default and checking permissions on every request. For a project owner, the useful question is whether the team can demonstrate those boundaries through direct requests, not merely show that a button is absent from the interface. OWASP reference

Build a permission plan people can maintain

1. 01

   List meaningful actions

   Separate viewing, creating, editing, deleting, exporting, approving, and administering. These are different responsibilities.

2. 02

   Add record scope

   Identify whether access applies to owned, assigned, team, or client records. Document how a user becomes associated with those records.

3. 03

   Cover changes over time

   Decide what happens when someone changes teams, leaves a client, or no longer needs access. Include active sessions and queued work in the review.

4. 04

   Assign administration carefully

   Name who grants roles and reviews access. Make emergency access explicit rather than sharing a powerful account across the team.

Test more than the navigation menu

• A client opens a direct link to another client’s file.
• A staff member calls an action available only to a manager.
• An employee removed from a project refreshes an existing session.
• An export includes records outside the user’s visible scope.
• A background automation runs after its initiating user loses access.

The application can make permissions easier to understand with clear role descriptions and an access review screen. Avoid creating many nearly identical roles just to handle every exception. If permissions depend on relationships or context, document that logic directly instead of hiding it in a confusing role name.

Review access as the team changes

Include access review in onboarding, role changes, and offboarding. Keep an audit trail of important grants and administrative changes. Test the permission matrix again when adding a new portal, export, AI assistant, or integration, since each can create another path to the same information.