Home / Knowledge hub / ABAC
Knowledge hub
ABAC
Permissions decided by attributes like department, location or data label, not just role.
What it means
ABAC stands for attribute-based access control. Instead of asking only "what role does this person have?", as role-based access control does, it evaluates a rule over facts: who the person is, what the data is, what action is requested and the context, such as time or location.
A rule might read: a support agent may view a ticket if the ticket belongs to their region and is not marked restricted. The same agent, the same screen and a different ticket can give a different answer. The decision comes from the rule and the facts at that moment, not from a fixed label.
Why it matters
Roles get clumsy as a product grows. You end up with dozens of narrow roles, each a small variation on another, and nobody can say exactly what any of them allows. Attributes let one rule cover many cases, and they match how real policies are written.
The cost is that mistakes are harder to see. A rule that reads the wrong attribute, trusts an attribute the person can edit, or has a gap for missing values may allow far more than intended. This is how property-level and cross-account leaks creep in.
How it shows up
You meet it in multi-tenant products where access depends on the customer, region, owner or sensitivity of a record, and in cloud policies that use tags. It is formalised in NIST SP 800-162. Often it is combined with roles, with policy as code holding the rules in one place.
Check where each attribute comes from. If a person can change their own department, or an object's owner field can be set in a request, the rule is only as strong as that field. Test missing and unexpected values, and make sure the decision happens on the server and that a missing attribute means deny by default.
Questions people ask
ABAC, answered
What is the difference between ABAC and RBAC?
RBAC decides by the role a person holds. ABAC decides by a rule over attributes of the person, the resource, the action and the context. Many systems use roles for the broad strokes and attributes for the details.
Is ABAC more secure than RBAC?
Not by nature. It is more flexible and can be more precise, but it is also easier to get subtly wrong. The security comes from correct rules and trustworthy attributes.
Where do the attributes come from?
From your directory, your database and the request. The ones that can be altered by the person they describe, or set by a client, should not be trusted for access decisions.
What does NIST say about it?
NIST SP 800-162 defines ABAC and describes how to plan, deploy and govern it. It covers the architecture of decision and enforcement points and the attributes feeding them.
How do we test ABAC rules?
Try requests with changed or missing attributes, records owned by another customer or region, and combinations the author did not expect. A correct rule refuses the request every time.
Related
Terms that sit next to this one
RBAC
Permissions attach to roles, and people are given roles.
Access control
The rules deciding which person can see or do which thing in your app.
Policy as code
Writing access rules as versioned, testable code instead of settings clicked by hand.
Object-level authorisation
Checking access to each individual record, not only to the type of record.
Broken object property level authorisation
Seeing or changing single fields of a record that you should not.
Which attribute can someone change?
Attribute-based rules are tested on the running app by changing the values they depend on, and each finding shows the request and response that proved the access. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.