Security

Security model layers

Layer 1: Transport         HTTPS everywhere, TLS 1.2+
Layer 2: Authentication    PASETO v4 (Ed25519) + JWT fallback
Layer 3: Authorization     RBAC roles (owner, admin, operator, viewer)
Layer 4: Tenant Isolation  Tenant ID scoping + PostgreSQL RLS
Layer 5: Network           CIDR allowlisting via square-dbctl + UFW
Layer 6: Audit             Immutable event log for all sensitive actions
Layer 7: VPS Hardening     fail2ban, crowdsec, opsdc role, NOSUPERUSER

Authentication security

PASETO v4 offline verification

AxiomDB verifies PASETO v4 tokens offline using Ed25519 cryptography. No request to the Square IdP is needed per API call. Token verification steps:

1. Split token into version.purpose.payload_b64.footer_b64
2. Validate version is v4 and purpose is public
3. Decode footer, check alg = "v4.public" and typ = "paseto"
4. Extract 64-byte signature from the end of the decoded payload
5. Verify using Pre-Authentication Encoding (PAE) against the IdP's Ed25519 key
6. Validate iss, exp, nbf (with 30 second clock skew tolerance)
7. Extract token_use = "access" claim
8. Extract ctx.tenant_id for tenant isolation

Token security constraints

Tenant isolation

Every resource in AxiomDB is scoped to a tenant_id derived from the Square IdP's OAuth2 ctx.tenant_id claim. This means users in different organizations can never see each other's data, even if they share the same AxiomDB deployment.

Two-layer enforcement

1. Application-level — Every SQL query includes WHERE tenant_id = $N. This is the primary enforcement layer, checked for every read and write.

2. Database-level — PostgreSQL Row-Level Security (RLS) is enabled on all tables as a safety net. RLS policies use current_setting('app.current_tenant', true), which is set at the start of every transaction.

-- Example RLS policy
CREATE POLICY tenant_isolation_projects ON projects
  USING (tenant_id = current_setting('app.current_tenant', true));

Tables with RLS enabled

• projects
• project_branches
• project_databases
• provisioning_jobs
• audit_events
• network_policies
• network_rules
• network_apply_events
• credential_events

Background worker bypass

Background workers use a dedicated PostgreSQL role axiomdb_bg_worker with the BYPASSRLS attribute. This role is used only for admin operations (provisioning, cleanup). Application queries always run under the normal role with RLS enforced.

Role-based access control

Role mapping from Square IdP claims:

• *.owner → owner
• *.admin → admin
• *developer* → operator

Network security

See Network & Access Control for full details. Security highlights:

• Default deny — All new projects start with mode = restricted (no external access)
• CIDR allowlisting — Rules applied to PgBouncer (port 6432) and PostgreSQL pg_hba.conf (port 5432) via UFW
• Expiring rules — Network rules can be set to auto-expire after a TTL
• Smart revocation — Deleting a rule only removes the firewall entry if no other rule covers the same CIDR

Audit logging

Every sensitive operation writes an immutable row to audit_events:

CREATE TABLE audit_events (
  id             UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  actor_user_id  UUID REFERENCES users(id),
  action         TEXT NOT NULL,
  target_type    TEXT NOT NULL,
  target_id      TEXT,
  metadata       JSONB NOT NULL DEFAULT '{}'::jsonb,
  tenant_id      TEXT NOT NULL,
  created_at     TIMESTAMPTZ NOT NULL DEFAULT now()
);

Audited actions

Query audit events

GET /api/v1/audit?project_id=...&action=branch.created&limit=50
Authorization: Bearer <paseto-v4-token>

CORS policy

CORS origins for the ops console are configured per-project. The gateway reads allowed origins from the control-plane DB and applies them as middleware.

GET /api/v1/projects/:project_id/cors
Authorization: Bearer <paseto-v4-token>

PUT /api/v1/projects/:project_id/cors
Authorization: Bearer <paseto-v4-token>
Content-Type: application/json

{
  "origins": ["https://myapp.com", "https://staging.myapp.com"]
}

VPS hardening baseline

AxiomDB deployments include the following hardening measures on the VPS:

Credential security best practices

• Never commit credentials. Use .env.local (gitignored) or a secrets manager.
• Use DATABASE_URL for runtime. Never expose DIRECT_URL to app servers — it bypasses PgBouncer.
• Rotate credentials after team member offboarding. Use POST /api/v1/projects/:id/credentials/rotate.
• Use expiring network rules for CI. Set "expires_in": "24h" for temporary CI/CD allowlist entries.
• Enable 2FA. Protect your AxiomDB account with TOTP (Settings → Security → Enable 2FA).