DEV Community

Alex Spinov
Alex Spinov

Posted on

Cerbos Has a Free API: The Open-Source Authorization Engine That Decouples Access Control From Your Application Code

A fintech startup ships a new feature. Three days later, a junior dev discovers that any logged-in user can see other users' bank statements. The fix takes 2 hours — but the real problem is structural: authorization logic is scattered across 47 controllers. This is the exact problem Cerbos solves.

What Cerbos Actually Does

Cerbos is an open-source, self-hosted authorization engine that acts as a sidecar to your application. Instead of writing permission checks in your code, you define policies in YAML files. Your app sends authorization requests to Cerbos via HTTP or gRPC, and Cerbos returns allow/deny decisions in under 1ms.

The key insight: policies live outside your codebase. Product managers can read them. Security teams can audit them. DevOps can deploy policy changes without touching application code. Cerbos supports RBAC, ABAC, and relationship-based access control out of the box.

Cerbos is fully open-source (Apache 2.0), runs as a single binary, requires zero external dependencies (no database needed), and has SDKs for Node.js, Python, Go, Java, Ruby, PHP, .NET, and Rust.

Quick Start

Run Cerbos locally:

docker run -d -p 3592:3592 -p 3593:3593 ghcr.io/cerbos/cerbos:latest
Enter fullscreen mode Exit fullscreen mode

Create a policy file policies/resource_document.yaml:

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  resource: "document"
  version: "default"
  rules:
    - actions: ["view", "edit"]
      effect: EFFECT_ALLOW
      roles: ["owner"]
    - actions: ["view"]
      effect: EFFECT_ALLOW
      roles: ["viewer"]
    - actions: ["view", "edit", "delete"]
      effect: EFFECT_ALLOW
      roles: ["admin"]
Enter fullscreen mode Exit fullscreen mode

Check authorization via API:

curl -X POST http://localhost:3592/api/check/resources \
  -H "Content-Type: application/json" \
  -d '{
    "requestId": "test-1",
    "principal": {
      "id": "user-123",
      "roles": ["owner"],
      "attr": {"department": "engineering"}
    },
    "resources": [{
      "resource": {
        "kind": "document",
        "id": "doc-456",
        "attr": {"owner": "user-123"}
      },
      "actions": ["view", "edit", "delete"]
    }]
  }'
Enter fullscreen mode Exit fullscreen mode

3 Practical Use Cases

1. Multi-Tenant SaaS Authorization

One YAML rule ensures admins can only access their own tenant's projects:

resourcePolicy:
  resource: "project"
  rules:
    - actions: ["*"]
      effect: EFFECT_ALLOW
      roles: ["admin"]
      condition:
        match:
          expr: request.resource.attr.tenantId == request.principal.attr.tenantId
Enter fullscreen mode Exit fullscreen mode

2. Feature Flags Based on Plan

    - actions: ["use_ai_features"]
      effect: EFFECT_ALLOW
      roles: ["user"]
      condition:
        match:
          expr: request.principal.attr.plan in ["pro", "enterprise"]
Enter fullscreen mode Exit fullscreen mode

3. Time-Based Deploy Restrictions

    - actions: ["deploy"]
      effect: EFFECT_DENY
      roles: ["developer"]
      condition:
        match:
          expr: now().getDayOfWeek() in [6, 7]
Enter fullscreen mode Exit fullscreen mode

No weekend deployments — enforced at the policy level.

Why This Matters

Authorization is a cross-cutting concern that most teams get wrong by embedding it in application code. Cerbos makes it a dedicated, testable, auditable service. Sub-millisecond latency, YAML policies readable by non-engineers, and zero-dependency architecture that runs anywhere.

For any application handling sensitive data, separating authorization from business logic is a security requirement that Cerbos makes trivially easy.


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!

Top comments (0)