Short answer: Before launch, prove tenant isolation and privileged workflows, harden identity and recovery, verify billing and webhooks, remove production secrets from code, and rehearse detection, backup and incident-response paths.
1. Define the launch threat model
List the data and actions that would damage customers: cross-tenant reads, account takeover, administrator abuse, subscription manipulation, leaked API keys and destructive operations. Map anonymous, member, workspace admin, internal support and service identities. Assign an owner and verification method to each control.
2. Prove tenant isolation and privileged actions
Scope every data query and storage path to the tenant derived from the authenticated session, not a body parameter. Test users with the same role in different tenants. Add distinct permissions and audit events for invitations, role changes, exports, deletion, support impersonation and ownership transfer.
test("workspace B cannot export workspace A", async () => {
const response = await api.as(adminB).post(`/workspaces/${workspaceA.id}/export`);
expect([403, 404]).toContain(response.status);
expect(await exportQueue.countFor(workspaceA.id)).toBe(0);
});3. Harden identity and recovery
Use a maintained authentication provider or library, secure session cookies, MFA for internal and high-privilege accounts, and server-side session revocation. Password reset, email change and MFA reset are authentication flows too: use single-use expiring tokens, generic responses and notifications for sensitive changes.
4. Verify billing, webhooks and integrations
Derive price and entitlement on the server. Verify webhook signatures over the exact raw body, reject stale events where the provider supports timestamps, handle events idempotently and fetch authoritative state when necessary. Store third-party tokens encrypted with least privilege and document rotation and revocation.
For outbound callbacks and import-by-URL features, apply SSRF defenses and egress restrictions. Treat AI tool calls and retrieved content as untrusted input; authorize the tool action independently of the model output.
5. Prepare production operations
Separate production secrets from builds and rotate any credential that entered source history. Send structured security events for login, recovery, role, billing and destructive actions without logging sensitive values. Test backup restoration, alert delivery and the ability to revoke sessions, webhook secrets and repository access.
Common mistakes
- Testing only with one tenant and one administrator account.
- Trusting a client-supplied plan, price or role.
- Parsing a webhook body before signature verification.
- Giving support accounts permanent broad access without audit events.
- Having backups without a measured restoration test.
- Calling the launch secure because dependency scanning is green.
Launch gate
- Cross-tenant negative tests cover reads, writes, exports and files.
- Privileged actions have separate permission and audit events.
- Session, recovery and MFA reset paths are tested.
- Price and entitlement are server-authoritative.
- Webhook signatures, replay handling and idempotency are verified.
- Secrets have owners, least privilege and rotation procedures.
- Security logs reach an alert someone will receive.
- Backup restoration and an incident contact path were rehearsed.
Limits
This gate is not a certification and does not cover every production dependency. Infrastructure, cloud IAM, mobile clients, desktop agents and regulated data can require separate controls. Repeat the threat model when roles, billing, integrations or tenant architecture change.
Primary sources
Related resources
Review a SaaS before launch
Apply these controls to the actual code and product boundaries.