Home / Knowledge hub / RBAC
Knowledge hub
RBAC
Permissions attach to roles, and people are given roles.
What it means
RBAC means role-based access control. Rather than granting permissions person by person, you define a handful of roles such as viewer, support and admin, decide what each role may do, and give people roles. NIST's model, standardised as INCITS 359, works the same way.
The point is manageability. When somebody joins, changes team or leaves, you change one role instead of hunting through dozens of individual settings. It only counts if the server checks the role on every request.
Why it matters
Roles keep access proportionate as headcount grows. Without them permissions drift, and the person who covered support one weekend still has the admin screen two years later.
Roles are also what a customer's security team asks about. A clear list of roles, and what each one may reach, is worth more in a review than any amount of general assurance. Keep the list short as well. Thirty roles, each invented for one person, brings back the problem you were solving.
How it shows up
The common failure is a role that exists in the interface and not in the code. The admin menu is hidden from a support user, and the underlying URL still answers when they type it. OWASP puts it plainly: never rely on a check that runs in the browser. Retest after any release touching navigation or permissions, because that is when a menu and a check stop agreeing.
Testing it honestly means one account per role and one attempt at every route with every account. Cyberlop builds that role by resource matrix and walks it, so gaps appear as a grid rather than a hunch.
Questions people ask
RBAC, answered
What is the difference between RBAC and ABAC?
RBAC answers who holds which role and what that role may do. Attribute-based access control adds conditions: the time, the network, whether the record belongs to the person asking.
NIST's guide to ABAC covers the trade, and the short version is that RBAC is simpler to explain and less able to express exceptions.
How many roles is too many?
The warning sign is not a count, it is a catalogue where many roles differ by one permission. That is role explosion, and it usually starts when every exception becomes a new role.
Keep roles coarse and handle the exceptions some other way, such as a time-limited elevation.
Do we have to choose one model?
No. Plenty of systems run roles for the broad strokes and attribute checks for ownership and context, which is normally the practical answer.
Start with roles, because you can explain them to a customer, and add conditions where the roles cannot express what you mean.
Is hiding the menu enough?
No, and it is the single most common failure in this area. Hiding a link changes what a person sees, not what the server accepts.
Anybody can type the URL, and an attacker reads your front-end bundle to find out which URLs exist.
How do we test that roles are enforced?
Create one account per role, then send every role's requests from every other role's session and record what the server returned.
Doing it by hand takes hours and gets skipped. Automating it turns the result into a grid you can read in a minute.
Related
Terms that sit next to this one
Access control
The rules deciding which person can see or do which thing in your app.
Authorization
Deciding what a proven user is then allowed to do.
Least privilege
Giving every person and service the minimum access the job requires.
Vertical privilege escalation
Climbing to a higher level of access than your account was granted.
Are your roles enforced or hidden?
Cyberlop signs in as every role you have defined and tries every route with each one, then shows the gaps as a grid you can read in a minute. Start a $199 pilot on one application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.