Why Your Authorization Logic is Probably Broken and How ReBAC Fixes It

TLDR: Traditional access control models like RBAC and ABAC often fail to handle the complex, dynamic relationships found in modern web applications, leading to Broken Access Control vulnerabilities. Relationship-Based Access Control (ReBAC) shifts the focus from static roles to a graph-based model of entities and their connections. By decoupling authorization logic from the application code, developers can enforce fine-grained security policies that are easier to audit and maintain.

Authorization is the hardest part of building a secure application. Most developers start with simple Role-Based Access Control (RBAC), assigning users to groups like "admin" or "editor." This works until the product manager asks for a feature where an editor can only modify articles they created, or perhaps only articles within a specific department, but only during business hours. Suddenly, your codebase is littered with nested if statements and complex database queries that are impossible to test and even harder to secure.

When you are on a penetration test, this is exactly where you look. You find the user_id in a request, change it to another valid ID, and watch the application fail to verify if the current user actually has a relationship with the requested resource. This is the root cause of most Insecure Direct Object Reference (IDOR) bugs.

The Failure of Static Models

RBAC is static. It assumes that if you have a role, you have access. ABAC (Attribute-Based Access Control) tries to solve this by adding context, like time of day or location, but it often becomes a maintenance nightmare. As the number of attributes grows, the policy logic becomes brittle.

ReBAC changes the paradigm by treating everything as an entity with relationships. Instead of asking "Does this user have the editor role?", you ask "Is there a path in the graph from this user to this document via an 'editor' relationship?" This graph-based approach is inherently more flexible. If the relationship between a user and a document changes, you update the graph, not the application logic.

Modeling Data with EAV

One of the most significant hurdles in implementing ReBAC is the database schema. If you try to map every possible relationship into a relational table, you end up with a massive, unmanageable schema that requires migrations every time a new relationship type is added.

The Entity-Attribute-Value (EAV) model, often used in Content Management Systems, provides a way to store this data without constant schema changes. By defining an Entities table and an Attributes table, you can store arbitrary relationships. In a ReBAC context, this means you can define a relationship like owner or member as a row in a table rather than a column in a database.

When you query this, you are essentially performing a join across your graph. For example, to check if a user can edit an article, you query the relationship graph:

SELECT E.EntityName, A.Attribute, A.Value
FROM Entities E
JOIN Attributes A ON E.EntityID = A.EntityID
WHERE A.InstanceID = ?
AND E.EntityType = 'Article';

This approach allows you to scale your authorization logic independently of your application data.

Practical Implementation with Permify

During his talk at DEF CON 2024, Ben Dechrai demonstrated how to implement this using Permify, an open-source authorization engine. The power of these tools lies in their ability to define policies in a domain-specific language that is separate from your application code.

Instead of writing:

if (user.isAdmin || (user.isEditor && document.editors.contains(user))) {
    // Access granted
}

You define the relationship in the engine:

entity document {
    relation owner @user
    relation editor @organisation#editor
}

This separation of concerns is a massive win for security. Your security team can audit the authorization policy in the engine configuration without needing to understand the entire application codebase. If you are a pentester, this is a goldmine. When you find an application using a centralized authorization engine, you are no longer looking for flaws in a thousand different if statements. You are looking for flaws in the policy definition itself.

Real-World Impact for Pentesters

On a typical engagement, you should look for where the application makes authorization decisions. If you see a call to an external service or a specific middleware that handles permissions, investigate how that service is configured. Are the relationships correctly defined? Is there a way to manipulate the graph to grant yourself unauthorized access?

The impact of a misconfigured ReBAC system is often catastrophic. Because these systems are designed to handle complex, nested permissions, a single logic error in the policy definition can lead to massive privilege escalation. If you can convince the system that you are a "member" of an "organization" that "owns" a sensitive document, you have effectively bypassed the entire security model.

Defensive Strategy

For developers, the goal is to move authorization out of the application code and into a dedicated layer. Use tools like Permify, OpenFGA, or Authzed to manage your permissions. These tools are built to handle the graph-based nature of modern authorization.

If you are building a new application, start by mapping out the relationships between your entities. Don't rely on roles alone. Ask yourself: "Who owns this? Who can edit this? Who can view this?" If you can answer these questions with a graph, you are already ahead of most of the industry.

Stop trying to patch broken access control with more if statements. Start building a graph. The next time you are auditing an application, look for the authorization engine. It is the most interesting part of the stack, and it is almost certainly where the most interesting bugs are hiding.