Cerbos Has a Free API: Add Authorization to Any App in 5 Minutes Without Writing Policy Logic

#security #api #webdev #opensource

You just shipped a multi-tenant SaaS app. Everything works great — until your biggest customer asks: "Can junior editors view but not delete published posts?" You spend three days tangling role checks across 40 endpoints. There has to be a better way.

That better way is Cerbos — and yes, it has a free API you can hit right now.

What Cerbos Actually Does

Cerbos is an open-source authorization engine that decouples your access control logic from your application code. Instead of scattering if (user.role === 'admin') checks everywhere, you write human-readable policies in YAML, and Cerbos evaluates them at runtime.

The core idea: your app asks Cerbos "Can user X do action Y on resource Z?" and Cerbos answers yes or no — instantly, based on the policies you defined. You get auditable, testable, version-controlled authorization logic that lives outside your codebase.

Cerbos works as a sidecar, a standalone service, or via their hosted Cerbos Hub. The self-hosted version is completely free and open-source (Apache 2.0). The API is straightforward REST — no special SDK required, though SDKs exist for Node, Python, Go, Java, and more.

Quick Start: Run Cerbos Locally

Get Cerbos running in under a minute with Docker:

docker run --rm --name cerbos \
  -p 3592:3592 -p 3593:3593 \
  -v /tmp/cerbos-demo/policies:/policies \
  ghcr.io/cerbos/cerbos:latest server

Create a simple resource policy at /tmp/cerbos-demo/policies/resource_post.yaml:

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  resource: post
  rules:
    - actions: ["view"]
      effect: EFFECT_ALLOW
      roles: ["editor", "admin", "viewer"]
    - actions: ["edit"]
      effect: EFFECT_ALLOW
      roles: ["editor", "admin"]
    - actions: ["delete"]
      effect: EFFECT_ALLOW
      roles: ["admin"]
    - actions: ["edit", "delete"]
      effect: EFFECT_ALLOW
      roles: ["editor"]
      condition:
        match:
          expr: request.resource.attr.ownerId == request.principal.id

Now check authorization with a single curl:

curl -s -X POST http://localhost:3592/api/check/resources \
  -H "Content-Type: application/json" \
  -d '{
    "requestId": "test-01",
    "principal": {
      "id": "user-42",
      "roles": ["editor"]
    },
    "resources": [
      {
        "actions": ["view", "edit", "delete"],
        "resource": {
          "kind": "post",
          "id": "post-123",
          "attr": {
            "ownerId": "user-42",
            "status": "draft"
          }
        }
      }
    ]
  }'

Response:

{
  "requestId": "test-01",
  "results": [
    {
      "resource": { "id": "post-123", "kind": "post" },
      "actions": {
        "view": "EFFECT_ALLOW",
        "edit": "EFFECT_ALLOW",
        "delete": "EFFECT_DENY"
      }
    }
  ]
}

Editor can view and edit their own post, but not delete it — exactly what the policy says.

3 Practical Use Cases

1. Multi-Tenant SaaS with Per-Org Permissions

Different organizations need different permission sets. With Cerbos you pass org attributes and derive permissions dynamically:

curl -X POST http://localhost:3592/api/check/resources \
  -H "Content-Type: application/json" \
  -d '{
    "principal": {
      "id": "user-99",
      "roles": ["member"],
      "attr": {
        "orgId": "org-abc",
        "plan": "pro"
      }
    },
    "resources": [{
      "actions": ["export"],
      "resource": {
        "kind": "report",
        "id": "report-55",
        "attr": { "orgId": "org-abc" }
      }
    }]
  }'

Your policy checks request.principal.attr.plan == "pro" and request.principal.attr.orgId == request.resource.attr.orgId — zero code changes when business rules change.

2. Batch Authorization Checks

Need to check permissions for a list of items (e.g., render a dashboard with actions enabled/disabled)? Send them all at once:

const { GRPC: Cerbos } = require("@cerbos/grpc");
const cerbos = new Cerbos("localhost:3593", { tls: false });

const decisions = await cerbos.checkResources({
  principal: { id: userId, roles: [userRole] },
  resources: documentIds.map(id => ({
    resource: { kind: "document", id },
    actions: ["view", "edit", "share", "delete"]
  }))
});

// O(1) lookup — all checked in one round-trip
const canEdit = decisions.isAllowed({ resourceId: "doc-1", action: "edit" });

One API call, no N+1 authorization queries.

3. Audit Trail Built-In

Cerbos logs every decision with the policy that triggered it. Enable audit logging:

# cerbos.yaml
audit:
  enabled: true
  backend: file
  file:
    path: /audit/cerbos-audit.log

Every authorization decision is recorded with timestamp, user, resource, action, effect, and which policy rule fired. Perfect for compliance requirements (SOC 2, HIPAA).

Why This Matters for Your Architecture

The real power of Cerbos isn't just cleaner code — it's organizational scalability. When your product, legal, and compliance teams want to change who can do what, they edit a YAML file and open a PR. No engineer touches application code. The policies are testable (cerbos compile validates them) and Git-auditable.

Compared to rolling your own RBAC: Cerbos handles edge cases you haven't thought of yet — attribute-based conditions, wildcard actions, derived roles, policy inheritance. Compared to cloud IAM systems: Cerbos is application-aware and designed specifically for "can this user do this action on this specific resource?" queries.

If you're building anything with more than two user roles, Cerbos is worth 30 minutes of your time.

Need custom data extraction or web scraping solutions? I build production-grade scrapers and data pipelines. Check out my Apify actors or email me at spinov001@gmail.com for custom projects.

Follow me for more free API discoveries every week!