When RBACWhat is rbac?Role-Based Access Control - assigning permissions to roles (like admin or editor), then giving users roles instead of individual permissions. Ask AI for more is not enough

RBAC breaks down when access rules depend on relationships or context:

If your access control rules include the words "own," "their," "assigned," or "during," you are describing ABACWhat is abac?Attribute-Based Access Control - an authorization model that makes decisions based on attributes of the user, resource, and environment rather than fixed roles. Ask AI for more policies, not RBAC.

The ABACWhat is abac?Attribute-Based Access Control - an authorization model that makes decisions based on attributes of the user, resource, and environment rather than fixed roles. Ask AI for more model

ABAC evaluates four categories of attributes to make access decisions:

Policy Engine
  ├── Subject attributes (who): role, department, clearance level, team
  ├── Resource attributes (what): owner, type, status, classification
  ├── Action attributes (how): read, write, delete, approve
  └── Environment attributes (when/where): time, IP, device, location

A policy is a rule that combines these attributes:

ALLOW action:update ON resource:post
  WHERE subject.id == resource.authorId
  AND subject.role IN ['editor', 'admin']
  AND resource.status != 'archived'

This single policy expresses: "Editors and admins can update posts they authored, as long as the post is not archived." Try expressing that with RBACWhat is rbac?Role-Based Access Control - assigning permissions to roles (like admin or editor), then giving users roles instead of individual permissions. Ask AI for more alone.

The ownership check: ABACWhat is abac?Attribute-Based Access Control - an authorization model that makes decisions based on attributes of the user, resource, and environment rather than fixed roles. Ask AI for more in practice

The most common ABAC pattern in web applications is the ownership check. It is so common that many developers implement it without realizing they are doing ABAC.

Here is the pattern AI generates when you ask for a "user can edit their post" feature:

// AI-generated: ownership check in the route handler
app.put('/api/posts/:id', authenticate, async (req, res) => {
  const post = await db.posts.findById(req.params.id);
  if (!post) return res.status(404).json({ error: 'Not found' });

  if (post.authorId !== req.user.id) {
    return res.status(403).json({ error: 'Not your post' });
  }

  await db.posts.update(req.params.id, req.body);
  res.json({ success: true });
});

This works for a single route, but the ownership check is buried in the handler. When you have 20 routes that need ownership checks, you end up with 20 slightly different implementations. Some check authorId, some check userId, some check createdBy, and some forget to check at all.

Extracting ABACWhat is abac?Attribute-Based Access Control - an authorization model that makes decisions based on attributes of the user, resource, and environment rather than fixed roles. Ask AI for more into a policy function

Instead of scattering ownership checks throughout your codebase, centralize them in a policy engine:

// Policy definitions: who can do what to which resource
const policies = {
  'posts:update': (subject, resource) => {
    // Admins can update any post
    if (subject.role === 'admin') return true;
    // Editors can update their own posts
    if (subject.role === 'editor' && resource.authorId === subject.id) return true;
    return false;
  },

  'posts:delete': (subject, resource) => {
    // Only admins can delete
    return subject.role === 'admin';
  },

  'posts:read': (subject, resource) => {
    // Published posts are readable by anyone authenticated
    if (resource.status === 'published') return true;
    // Drafts are only readable by the author or admins
    return resource.authorId === subject.id || subject.role === 'admin';
  },
};

// Generic policy check
function checkPolicy(action, subject, resource) {
  const policy = policies[action];
  if (!policy) return false; // Deny by default
  return policy(subject, resource);
}

Now every access decision is defined in one place. You can read all the rules at a glance, test them in isolation, and change them without touching route handlers.

ABACWhat is abac?Attribute-Based Access Control - an authorization model that makes decisions based on attributes of the user, resource, and environment rather than fixed roles. Ask AI for more middlewareWhat is middleware?A function that runs between receiving a request and sending a response. It can check authentication, log data, or modify the request before your main code sees it. Ask AI for more pattern

You can wrap the policy check into Express middleware that loads the resource and evaluates the policy before the handler runs:

function authorizeResource(resourceType, action, loadResource) {
  return async (req, res, next) => {
    const resource = await loadResource(req);
    if (!resource) return res.status(404).json({ error: 'Not found' });

    if (!checkPolicy(`${resourceType}:${action}`, req.user, resource)) {
      return res.status(403).json({ error: 'Forbidden' });
    }

    req.resource = resource; // Attach for handler to use
    next();
  };
}

// Usage
app.put('/api/posts/:id',
  authenticate,
  authorizeResource('posts', 'update', (req) => db.posts.findById(req.params.id)),
  async (req, res) => {
    // req.resource is already loaded and authorized
    await db.posts.update(req.resource.id, req.body);
    res.json({ success: true });
  }
);

The handler never touches access control. It only runs if the user is authenticated and authorized for the specific resource.

Policy engines for complex systems

For applications with dozens of resource types and complex rules, hand-written policy functions become hard to maintain. Policy engines externalize the rules into a declarative format:

These engines let you define, test, and audit policies without modifying application code. A policy change is a configuration update, not a code deployment.

RBACWhat is rbac?Role-Based Access Control - assigning permissions to roles (like admin or editor), then giving users roles instead of individual permissions. Ask AI for more vs ABACWhat is abac?Attribute-Based Access Control - an authorization model that makes decisions based on attributes of the user, resource, and environment rather than fixed roles. Ask AI for more: when to use which

Most applications do not need to choose one or the other. They use both:

The practical approach: start with RBAC for coarse-grained access (who can access which features), then layer ABAC for fine-grained resource-level rules (who can act on which specific records). This hybrid is what most production applications actually use.