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
LaunchRoom does not claim SOC 2, ISO 27001, HIPAA, or GDPR certification, and is not currently audited by a third party. We follow best practices (RLS, least-privilege grants, hashed tokens, 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.