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 status
LaunchSync operates under SOC 2 Type I compliant controls. The audit was completed in March 2026 and covers the cloud production environment and data handling policies. LaunchSync does not claim SOC 2 Type II, ISO 27001, HIPAA, or GDPR certification.
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.