Security architecture.

Application layer

Password hashing

bcrypt with per-user salt; plaintext passwords are never stored or logged.

Sessions

JWT-based session management with signed, expiring tokens.

Password reset

Rate-limited reset flow with a 60-second cooldown between attempts on the same account.

Email verification

Required on signup before the account can access any protected surface.

MFA (TOTP)

Self-service enrollment via QR code, compatible with any TOTP authenticator; enforceable organization-wide by an admin.

RBAC

Two roles: Admin and Member. Feature access is checked on every request against the caller's assigned role.

Role storage

Roles are stored in a separate table, not on the user profile — specifically to prevent privilege-escalation attacks that mutate a profile record.

Feature-based access

Feature toggles evaluated at both the user and organization level, with the organization value taking precedence.

Cloud and edge layer

JWT verification

All sensitive edge functions verify the caller's JWT before executing any logic; unverified requests are rejected at the boundary.

Error sanitization

Server-side errors are sanitized before being returned to clients to prevent information leakage (stack traces, internal identifiers, query fragments).

CORS

Controlled CORS configuration — allowed origins are enumerated, not wildcarded.

Service role isolation

The service role key is used only from server-side code paths. All user-initiated operations run under an anonymous key subject to row-level security.

Database layer

Row-level security is enabled on every table. Policies are granular per operation — SELECT, INSERT, UPDATE, DELETE are evaluated independently, not collapsed into a single ALL policy.

SELECT

Requires organization membership or admin role.

INSERT

Requires an authenticated user.

UPDATE

Requires owner, organization member, or admin.

DELETE

Requires owner or admin only.

Security-definer functions

Used for role lookups to prevent RLS recursion when a policy needs to check the caller's role against a table that itself has RLS enabled.

Multi-tenancy

organization_id

Every core entity table carries an organization_id column that scopes the row to a single tenant.

RLS enforcement

Organization boundaries are enforced at the database layer via RLS — not just in application code — so a bypassed API cannot leak cross-tenant data.

New users

New users must be assigned to an organization before they can create, read, or modify any core entity.

Audit and deletion safeguards

Soft deletion

Core entities are soft-deleted by default; a deleted row is marked inactive and retained for the recovery window before hard deletion is possible.

Deletion log

Every deletion — soft or hard — is written to an append-only log with actor, timestamp, entity type, entity id, and reason.

Admin only

Deletion of core entities is restricted to admins; members can archive but not delete.

Exact-name confirmation

The admin must type the exact entity name to confirm a deletion — no click-through confirmation.

Reason required

A minimum 10-character reason is required and is written to the deletion log.

Cascading impact

Before confirmation, the UI displays the full cascade — child records, dependent references, and downstream artifacts that will be affected.