Security
Security notes
RLS, scoping, data boundaries, and production hardening expectations.
RLS expectations
Every app table has Row-Level Security enabled. Policies use security-definer helpers (is_org_member, is_org_owner, user_can_access_launch) so policy logic is centralized and auditable.
Organization scoping
Workspace tables (launches, activity_logs) are scoped by organization_id. A user only sees rows in organizations they are a member of.
User data boundaries
Per-user tables (profiles, email_preferences, notification_settings, consent_records) are restricted to the owning auth.uid() for select and update.
Safe public unsubscribe
Unsubscribe and email-preferences pages work without sign-in via opaque tokens stored hashed in unsubscribe_tokens. The tables themselves have no public read access — token verification happens in a security-definer function.
Compliance claims
SOC 2 Type II is in progress; gap analysis completed May 2026. LaunchDock does not claim ISO 27001, HIPAA, or GDPR certification. We follow documented practices (AES-256 at rest, TLS 1.3 in transit, RBAC across Owner, Admin, Editor, and Viewer, immutable readiness override logs, least-privilege grants, opt-in marketing) but do not present those practices as certifications.
Required production hardening
- Configure custom SMTP and verified sending domain before high-volume marketing.
- Rotate the Supabase service role key and any admin secrets before going live.
- Enable leaked-password protection in Supabase Auth settings.
- Set short OTP expiry (≤ 1 hour) and require email confirmation.
- Add monitoring and alerting on auth failures and edge function errors.
- Run a dependency and security scan in CI before each release.