Security overview

Verifiable description of how authentication, data isolation, and protection are implemented. No unverified compliance claims.

Last updated: March 2025

Summary

  • • Session-based authentication (Supabase Auth) with secure cookies
  • • Row-level security (RLS) and workspace-based isolation in the database
  • • Append-only audit logs; export via API
  • • GDPR export and erasure via API

Data handling · Incident response · Subprocessors

Authentication

Method: Supabase Auth. Users sign in with email/password or, when enabled, OAuth (Google, Azure AD) via Supabase. Sessions are maintained with HTTP-only, SameSite cookies. The server validates the session on each request for protected routes (middleware and getSessionOr401() in API routes).

API access: Optional API keys (stored as SHA-256 hash; prefix only in DB). Keys are scoped to the user and revocable.

Database isolation

Model: PostgreSQL (Supabase) with Row Level Security (RLS) enabled on application tables. Policies enforce that users can read and write only rows where user_id = auth.uid() (or, for workspace-scoped resources, where the user is a member of the relevant workspace with the required role). Projects, reports, experiments, pipelines, datasets, workspace_members, and related tables are all protected by RLS. There is no application path that bypasses RLS for tenant data; the service role is used only for specific backend operations (e.g. GDPR delete, audit export with a compliance key).

Workspaces: Workspace membership (owner, admin, editor, viewer) gates create/edit/delete and billing; RLS policies restrict visibility to workspaces the user belongs to.

Data encryption

In transit: All client–server and server–database traffic is sent over HTTPS/TLS. The application does not serve the app over plain HTTP in production; hosting must enforce TLS.

At rest: Database and file storage are hosted by Supabase (or your own infrastructure if self-hosted). Encryption at rest is provided by the infrastructure provider (Supabase documents encryption at rest for their managed Postgres). The application does not implement application-level encryption of stored data; reliance on encryption at rest is on the provider. Verify with your deployment target (e.g. Supabase Dashboard or your cloud provider) for current capabilities.

Audit and monitoring

  • Audit trail: Activity and usage logs are append-only (no UPDATE/DELETE in application or RLS). Export via audit export API (compliance key required).
  • Errors: When configured, errors can be sent to Sentry; see Subprocessors.

Related