AUTHORIZATION FOR THE ENTIRE TYPESCRIPT STACK

Define permissions once. Enforce them everywhere.

One authorization model for frontend, backend, and database. No extra infrastructure.

import { createMongoAbility, AbilityBuilder } from '@casl/ability';
import { accessibleBy } from '@casl/mongoose';

// Define permissions once
const { can, cannot, build } = new AbilityBuilder(createMongoAbility);

can('read', ['Post', 'Comment']);
can('manage', 'Post', { author: 'me' });
can('create', 'Comment');

const ability = build();

// Enforce them across your application
ability.can('read', 'Post') // UI & API
accessibleBy(ability, 'update').ofType('Post') // Database conditions

By the numbers

Built with CASL

Using CASL? Showcase your project

POWERFUL PERMISSIONS. MINIMAL OVERHEAD

Isomorphic

Use the same authorization rules across frontend and backend, with integrations for popular frameworks and ORMs.

Versatile

From simple claim-based checks to action/resource permissions, supporting both RBAC and fine-grained ABAC.

Serializable

Define permissions once. Serialize and share rules across frontend, APIs, and microservices.

TypeSafe

TypeScript-first APIs catch mistakes early and provide a better developer experience.

Tree shakable

Just 6.8kB minified and gzipped, with tree shaking to keep bundles even smaller.

BUILT TO EVOLVE WITH YOUR APPLICATION

Start simple. Scale with complexity.

From basic permissions to roles, attributes, and relationships — using the same authorization model.

01 / A CAPABILITY

Claims

Start with feature access or simple capabilities expressed as actions.

A stable API for simple permissions, ready to gain resource context when you need it.

import { AbilityBuilder, createMongoAbility } from '@casl/ability';

const { can, build } = new AbilityBuilder(createMongoAbility);

can('read:project');
can('update:project');
can('manage:workspace');

const ability = build();

ability.can('update:project'); // true

02 / ADD A RESOURCE

Actions / Subjects

Give every layer a shared vocabulary: what action, on which resource?

The same capability vocabulary now distinguishes articles, projects, and workspaces.

import { AbilityBuilder, createMongoAbility } from '@casl/ability';

const { can, build } = new AbilityBuilder(createMongoAbility);

can('read', 'Project');
can('update', 'Project');
can('manage', 'Workspace');

const ability = build();

ability.can('update', 'Project'); // true

03 / GROUP PERMISSIONS

RBAC

Map roles to rules once, instead of scattering role checks across features.

Roles become bundles of action/resource permissions.

import { AbilityBuilder, createMongoAbility } from '@casl/ability';

const { can, build } = new AbilityBuilder(createMongoAbility);
const user = { role: 'projectAdmin' };

can('read', 'Project');
if (user.role === 'projectAdmin') can('update', 'Project');
if (user.role === 'workspaceAdmin') can('manage', 'Workspace');
const ability = build();

ability.can('update', 'Project'); // true

04 / ADD CONTEXT

ABAC

Refine permissions with ownership, tenant identity, or resource state.

Roles can still grant permissions; attributes constrain which records those grants cover.

For object checks, subject identifies a plain object as a Project so ability.can applies Project rules to its attributes. See subject type detection .

import { AbilityBuilder, createMongoAbility, subject } from '@casl/ability';

const { can, build } = new AbilityBuilder(createMongoAbility);
const user = { tenantId: 'tenant-1', role: 'projectAdmin' };

can('read', 'Project', { tenantId: user.tenantId });
if (user.role === 'projectAdmin') {
  can('update', 'Project', { tenantId: user.tenantId });
}
if (user.role === 'workspaceAdmin') {
  can('manage', 'Workspace', { tenantId: user.tenantId });
}

const ability = build();
const project = subject('Project', { ... });
ability.can('update', project); // true

05 / FOLLOW RELATIONSHIPS

ReBAC

Add workspace membership and resource administrator relationships on top of tenant isolation.

Denormalized SQL relations

Denormalized: Fast, local permission checks. Requires keeping derived membership attributes synchronized.

For object checks, subject identifies a plain object as a Project so CASL checks Project rules against its relationship attributes. See subject type detection .

import { AbilityBuilder, createMongoAbility, subject } from '@casl/ability';

const { can, build } = new AbilityBuilder(createMongoAbility);
const user = { id: 'alice', tenantId: 'tenant-1', role: 'projectAdmin' };

can('update', 'Project', {
  tenantId: user.tenantId,
  projectAdminIds: { $in: [user.id] },
  workspaceMemberIds: { $in: [user.id] }
});

const ability = build();

const project = subject('Project', {
  tenantId: 'tenant-1',
  workspaceMemberIds: ['alice'],
  projectAdminIds: ['alice']
});
ability.can('update', project); // true

These approaches can coexist. Combine them as your authorization requirements evolve.