Security and data integrity by design.

Postgres RLS policies enforce tenant isolation at the database layer. Every query is filtered by org_id or equivalent before rows are returned. Policies apply to all access paths—API, direct SQL, Edge Functions—so there is no bypass. RLS is the primary defense against cross-tenant data leakage.

Sessions are scoped to a tenant. JWT claims include org_id and role. Supabase Auth (or equivalent) sets these at login. RLS policies read from current_setting(). Users cannot escalate scope or role via client requests.

APIs validate JWT on every request. Rate limiting and input validation are applied at the edge. Sensitive operations require re-authentication or step-up. No secrets in client bundles; server actions and API routes handle privileged operations. CORS and security headers are configured explicitly.

Stripe handles card storage and processing. We never touch raw card data. PCI scope is minimized by using Stripe Elements or Checkout. Webhook signatures are verified before processing. Idempotency keys prevent duplicate charges. Stripe maintains SOC 2 and PCI DSS compliance; we rely on their attestations for payment security.

Secrets live in environment variables, never in code. CI/CD runs tests before deploy. Staging mirrors production configuration. Database migrations are versioned and reversible. Logs exclude PII. HTTPS everywhere; HSTS and secure cookies enabled. Regular dependency updates and automated security scanning where available.