SaaS launch security checklist for vibe-coded apps

Use a staging environment with production-like authorization settings and synthetic data. Create tenant A and tenant B, each with an account and a private test record. Add an ordinary member and an administrator when your app has roles. Keep a separate browser profile with no login. Use your own mailboxes and a Stripe sandbox; do not use customer records or real charges for these checks.

Write the expected permissions before testing. For example: an A member may read A's document, cannot read B's document, and cannot invite an administrator. A visitor with no session cannot access either private document. If cross-tenant sharing is intentional, record exactly which operation is allowed.

In your own test environment, use browser developer tools to inspect a request for a private record. While signed in as A, repeat the request with B's known test record ID. Check both the response and stored data: hiding a button or returning an error message is insufficient if the server still performs the action. OWASP recommends checking authorization on every request.

Repeat the check for reads, edits, deletes, exports, invitations, and role changes that your app supports. Test the ordinary member against administrator-only actions. Confirm the legitimate owner can still perform the intended operation; blocking everyone can make a broken feature look protected.

If you use Supabase, review table grants and Row Level Security together. Exercise requests with the publishable or legacy anon key and no user session, then with each test user's session. Do not use an administrative SQL connection or a privileged server key to judge what a browser user can access. Test the roles and connection path the application actually uses.

Check SELECT, INSERT, UPDATE, and DELETE separately. For updates, test whether a user can change a row's owner or tenant; a policy must constrain the resulting row as well as the existing one. Verify policies against the deployed database rather than assuming a migration file reflects its current state.

Use a harmless test file to check storage permissions. As A, try to read, overwrite, and delete B's private file through the app's normal API path. Inspect bucket visibility and storage policies separately from table policies. Public buckets are intended for public content; a hard-to-guess filename is not a private-file access control.

Exercise login, password reset, account switching, and logout with your test accounts. Confirm session cookies use appropriate Secure, HttpOnly, and SameSite settings where your authentication design uses cookies. Inspect actual network responses rather than relying on a dashboard screenshot.

In a Stripe sandbox, complete one test purchase and confirm that the correct account receives the correct entitlement once. Opening a success URL or changing a browser-supplied plan must not independently grant paid access. Your server should verify the relevant Checkout Session and payment or subscription state; Stripe documents webhooks as necessary for reliable fulfillment.

Verify webhook signatures against the raw request body with the signing secret for that endpoint. Test an invalid signature and confirm it causes no entitlement change. The secret used by a local Stripe CLI listener can differ from the registered endpoint's secret.

Scan the final public hostname after deploying. ScanMySaaS can inspect observable signals such as headers, transport, cookies, and exposed files on reachable public pages. Its separate public GitHub scan reads a bounded set of files from the current tree for security-relevant patterns. It does not execute the repository or search full Git history; private repository support is not part of that public scan.

These checks cannot prove the tenant, RLS, storage, session-revocation, or Stripe entitlement tests above have passed. A repository hint about a missing policy is not a live authorization test. A clean public report is not security certification. Record untested boundaries explicitly and use the relevant platform checks and manual review alongside the report.

Create one entry per failed check in your issue tracker. The format below works for a manual authorization failure or an automated public finding. Keep raw tokens and private customer data out of the entry.

Treat unauthorized access to another tenant's data, exposed privileged credentials, and incorrect paid entitlements as launch blockers until they are contained and fixed. Give other verified findings an owner and an explicit decision. Do not make every missing hardening header look like the same level of risk.

Keep the worksheet with the release and rerun affected checks after changes to authentication, database policies, billing, hosting, or membership rules. The useful outcome is a repeatable check and evidence of the fix, not a one-time score.