Does This Self-Hosted Application Give People Only the Access They Need? An RBAC Evaluation Checklist
Use this practical checklist to evaluate roles, permissions, administrator boundaries, API access and user lifecycle processes before moving users and data into a self-hosted application.
Why access-control design belongs before deployment
A migration can make an application technically available while leaving the organisation with a poor fit for how work is actually divided. If finance, sales, operations, client services and contractors all need different actions on different records, validate that model before importing production data or inviting users.
Role-based access control (RBAC) is built around identifying the operations required by particular jobs, assigning people to roles, and assigning privileges to those roles. The important buyer question is therefore not “Does it say RBAC?” but “Can we express and operate our required access decisions in this application?”
Treat least privilege as a design criterion: each person should receive the minimum privileges needed for their job. People at a similar seniority level can still require sharply different access because their duties differ. OWASP also recommends deny-by-default authorization, meaning access should be explicitly permitted rather than assumed.
- Evaluate permissions during selection, not after a production rollout has made broad access difficult to unwind.
- Do not equate an application’s use of the word “RBAC” with advanced capabilities. NIST distinguishes core role assignment from optional role hierarchies and separation-of-duty features.
- Make access-model fit a migration gate alongside data import, integrations, authentication and backup requirements.
Start with real user groups and the actions each group must perform
Begin with work, not with the application’s default role names. Interview the people accountable for each business process and record the smallest practical set of actions they must complete. Include normal work, exceptions, approvals, exports, deletion, user administration and configuration changes.
Avoid role labels that conceal broad privileges. “Manager,” “editor” or “member” is not a permission requirement. A useful requirement states a verb, an object and a scope: for example, “create records in the assigned workspace,” “view client-owned projects,” or “export only aggregated reports.”
Include negative requirements. These are the actions or data a group must not be able to access, alter, disclose or approve. They frequently reveal gaps that a list of allowed actions misses.
- List user populations: employees, team leads, executives, temporary staff, contractors, clients, partners, auditors and technical administrators.
- For each population, list actions: view, create, edit, comment, assign, approve, delete, export, share, configure and administer.
- Define scope for every action: own records, assigned records, team records, a workspace, a client account, all records or no records.
- Identify sensitive fields and high-impact actions separately from ordinary content access.
Identify the application’s access model: roles, groups, objects and boundaries
Ask the vendor or project documentation to show the exact access model for the version you plan to deploy. Record what is documented, what can be demonstrated in a test instance and what remains uncertain. Do not fill gaps with assumptions based on another application or a familiar role label.
At minimum, determine whether permissions are assigned through fixed roles, custom roles, groups, direct user grants or a mixture. Then determine the scope at which those permissions apply: the whole instance, an organisation, a team, a workspace, a project, a collection, a record or a field.
A workspace boundary can be useful only if it genuinely restricts access in the ways you need. Test whether people can search across boundaries, follow links to other objects, receive notifications containing restricted information, export cross-boundary data or gain access through inherited membership.
- Can you create a role that matches each requirement, without assigning unrelated privileges?
- Are roles global or can they differ by workspace, project, client or other business boundary?
- Can permissions be set at object or field level where your risk requires it?
- Are role hierarchies supported, and if so, do inherited privileges remain understandable and reviewable?
- Can direct grants bypass the normal role model, and how will those exceptions be found during review?
- What happens to access when an object, workspace or user is moved or copied?
Test administrator separation from sensitive business-data access
Operational administration and business-data access are different responsibilities. A team may need someone to manage users, routing, backups or application availability without routinely viewing confidential customer, employee or financial information. Establish whether the application supports that distinction rather than assuming that an administrator can be constrained appropriately.
Separation of duty addresses whether one person has enough privilege to misuse a system alone. It can be implemented through conflicting roles assigned in advance or through controls that restrict a conflicting action at the time of access. Whether either approach is necessary depends on your process and risk, but the question should be explicit for high-impact actions.
Also map the infrastructure boundary. Docker warns that control of a Docker daemon is highly privileged and can provide root access on the host. Likewise, supporting administrative interfaces need review; Traefik notes that a production API or dashboard can expose configuration elements, including sensitive data, and should be protected with authentication and authorization.
- Can a user administrator create accounts and reset access without reading ordinary business records?
- Can a content or workspace administrator manage membership without receiving unrestricted export or configuration privileges?
- Who can change roles, create privileged accounts, alter authentication settings, access backups or manage the deployment?
- Are sensitive actions logged in a way the organisation can review?
- For high-risk operations, should two distinct people be required for request and approval?
Check external collaborators, contractors and client users
External users often expose the difference between a general collaboration role and a safe client-access model. Their access may need a short expiry, a limited set of projects, no directory visibility, no export rights and no ability to invite others. Test these requirements with the application’s actual sharing and membership features.
Do not assume a restricted interface means restricted data. Verify what the external account can access through search, direct URLs, notifications, file attachments, comments, exports and APIs. Test a client user against another client’s representative records, not just against an empty environment.
If the application cannot express the required boundary, a separate instance, a separate workspace with carefully validated controls, a different sharing process or a different application may be safer. The right answer depends on the sensitivity of the data and the consequences of an error.
- Can external access be limited to named users and defined business scopes?
- Can invitations expire, and can access be removed promptly?
- Can external users discover other users, teams, clients or records?
- Can they download, export, copy or reshare information?
- Can they create users, invite collaborators or alter membership?
- Can the organisation review all active external accounts and their access?
Assess API tokens, service accounts and integrations separately
Human interface permissions do not prove that integrations are safe. APIs can expose administrative or sensitive functions if endpoint-level authorization is missing or too broad. OWASP specifically identifies broken function-level authorization as a risk when administrative endpoints are accessible without suitable checks.
Inventory every non-human identity: API tokens, integration credentials, automation users, service accounts and webhooks where applicable. For each one, identify its owner, purpose, permissions, scope, storage location, rotation process and revocation method. A token should not inherit an all-powerful human administrator’s access merely because it was convenient to create.
Test integrations using the same representative scopes as people. A reporting integration that needs aggregate data should not automatically receive the ability to modify records or administer users. Keep development, test and production credentials distinct where your operating model supports that separation.
- Does the application support scoped credentials, or is each token effectively full-account access?
- Can tokens be attributed to an individual owner or a named service purpose?
- Can permissions be limited by action, resource scope or expiration?
- Can a token be revoked without disabling unrelated integrations?
- Do API responses honor the same intended boundaries as the user interface?
- Are administrative endpoints and functions tested explicitly, not inferred from interface restrictions?
Create a permission test matrix with representative records and non-production accounts
A permission test matrix turns access requirements into evidence. Create representative test users for each role, including a deliberately low-privilege account and an external account. Create representative records that cover ordinary, confidential, cross-team, cross-client, archived and ownership-transfer scenarios relevant to your organisation.
For each role and action, state the expected result: allowed, denied or allowed only within a named scope. Test through all available paths, including the user interface, direct links, search, exports, bulk actions, mobile clients if used, notifications and APIs. Authorization testing should cover denied paths as well as successful user journeys.
Retest when roles, integrations, major workflows or application features change. OWASP notes that authorization issues often arise when features are added or modified without re-evaluating authorization behavior.
- Use rows for representative roles and columns for actions and data scopes.
- Record both expected and observed results, plus evidence such as a test date, account name and result reference.
- Test read, create, edit, delete, share, export, invite, role-change and configuration actions where relevant.
- Include attempts to access another team’s, client’s or workspace’s data.
- Add regression tests for the highest-risk authorization rules where your team has the capability.
Plan joiner, mover and leaver processes
Even a well-designed role model fails if accounts and memberships are not kept current. Define how a person gains access, changes access when their role or client assignment changes, and loses access when employment, a contract or a project ends. Assign a named owner for each step and set an operational review cadence appropriate to the risk.
If the application supports SCIM, the protocol provides operations for User and Group resources, including creating, retrieving, modifying and deleting them. That can support provisioning workflows, but it does not decide your lifecycle triggers, role design, ownership-transfer rules or exception handling. Those remain organisational responsibilities.
Pay particular attention to ownership. Before disabling an account, determine who will own active records, projects, queues, files, automations, reports and integration credentials associated with that user. Confirm that transfer does not unintentionally broaden the recipient’s access.
- Joiner: verify identity, select the approved role, set the correct scope and record the approving manager or owner.
- Mover: remove obsolete access before or when adding new access; review direct grants and external memberships.
- Leaver: disable or remove access, revoke tokens, transfer ownership and review shared resources.
- Contractor or client end date: use a scheduled review and confirm removal, rather than relying on a remembered manual task.
- Periodically review privileged, external, inactive and exception accounts.
Frequently asked questions
What should be included in a self-hosted application RBAC checklist?
Include real user groups, required and prohibited actions, data scope, roles and groups, workspace or object boundaries, administrator separation, external-user controls, API and service-account permissions, a permission test matrix, and joiner-mover-leaver processes. Document what has been demonstrated versus what is only assumed.
Does managed hosting provide application RBAC?
Managed infrastructure and application authorization solve different problems. Airbip manages cloud infrastructure around Docker-based application deployments, including routing, TLS certificates, lifecycle management and configurable backups. The customer still needs to select an application whose permission model fits the organisation, define roles and access scopes, and operate access governance appropriately.
Is a role called administrator always too powerful?
Not necessarily, but it must be tested. Determine exactly what the administrator can view, change, export and delegate, and whether operational administration can be separated from sensitive business-data access. Also review supporting infrastructure administration because those privileges can be highly sensitive.
Why test API permissions if the user interface looks restricted?
User-interface restrictions do not demonstrate that API endpoints enforce the same authorization rules. Test API functions separately, especially administrative functions, exports and cross-scope access. Inventory and restrict tokens and service accounts according to their specific purpose.
When is a self-hosted application not the right fit for the required access model?
Choose another application or deployment approach when the required boundaries cannot be expressed and verified without broad exceptions; when external users cannot be isolated safely enough; when sensitive actions require separation that the system cannot support; or when the team cannot operate the necessary access reviews, testing and lifecycle processes. Managed infrastructure does not compensate for an unsuitable application-level authorization model.
Sources and further reading
- Role Based Access Control FAQs — National Institute of Standards and Technology
- Authorization Cheat Sheet — OWASP Foundation
- Authorization Testing Automation Cheat Sheet — OWASP Foundation
- API5:2023 Broken Function Level Authorization — OWASP Foundation
- Separation of Duty glossary entry — National Institute of Standards and Technology
- SP 800-53 Rev. 5 controls download page — National Institute of Standards and Technology
- RFC 7644: System for Cross-domain Identity Management Protocol — IETF
- Docker Engine security — Docker
- Protect the Docker daemon socket — Docker
- API & Dashboard — Traefik Labs