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
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"]
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"]
}]
}'
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
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"]
3. Time-Based Deploy Restrictions
- actions: ["deploy"]
effect: EFFECT_DENY
roles: ["developer"]
condition:
match:
expr: now().getDayOfWeek() in [6, 7]
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)