The pre-launch security checklist for AI-built apps

How to use this list

You don’t need a security background. Set up two test accounts, keep this page open and work through it section by section. Anything you can’t confidently tick is worth fixing, or worth asking someone to check, before launch.

1. Your database and user data

• Every table holding user data has row-level security on (Supabase) or locked-down security rules (Firebase). How to check your Supabase RLS or Firebase rules.
• No private table is readable by everyone. Look for using (true) policies in Supabase, or allow read, write: if true in Firebase rules.
• User A can’t see or change User B’s data. Sign in as one test account and try to open the other’s records, for example by changing an ID in the URL or in a request.
• Uploaded files are private. Private uploads live in a private bucket, and one user can’t download another’s files by guessing a link.

2. Keys and secrets

• No secret key reaches the browser: OpenAI, Anthropic, Stripe secret, or Supabase secret / service_role. How to check for exposed keys.
• Your .env file was never committed to your repository.
• Every key that was ever exposed has been rotated, not just removed from the code. What to do when a key leaks.
• Spending limits and alerts are set with your AI provider.

3. Logins, pages and API routes

• Every API route checks who’s calling on the server. Hiding a button in the interface doesn’t stop someone calling the route directly.
• Admin pages and actions are checked on the server, not just hidden from the menu for regular users.
• Users can’t make themselves admins by editing a role or is_admin field on their own profile.
• Error messages don’t leak details like stack traces, SQL queries or internal file paths.

4. Your AI features

• Your system prompt contains no secrets. Assume users can get the AI to repeat its instructions, because they often can.
• The AI can only reach the current user’s data. If it searches documents or a database, that search must apply the same permissions as the rest of your app.
• Actions the AI can take are checked on the server. If your assistant can send emails, change records or spend money, the server confirms the user is allowed to do that, whatever the AI was told.
• AI endpoints require login and are rate limited, so strangers can’t run up your bill.
• AI output is treated as untrusted. Don’t render it as raw HTML or run it as code, since a crafted message or document can make the AI produce anything.

5. Payments

• Prices come from your server, never from a value the browser sends.
• Paid access is granted only after your server confirms the payment, for example via a verified Stripe webhook, not because the browser landed on a “success” page.
• Webhook signatures are verified, so nobody can fake a “payment succeeded” event.

A prompt to start the review in your AI tool

Your coding tool can help you work through this list. Treat its answers as a starting point, not a sign-off, and test the important items yourself with two accounts.

Review this app for launch security. For each item, tell me whether it is
handled, show me where in the code, and propose a fix if it is not:
- Row-level security / security rules on every table with user data
- Users cannot read or change other users' data or files
- No secret API keys in frontend code or client-side env vars
- Every API route and admin action checks the user on the server
- AI features only access the current user's data, are rate limited,
  and their output is never rendered as raw HTML
- Prices and paid access are verified on the server (Stripe webhooks
  with signature verification)
Do not change anything yet; give me the list first.

Want it checked by hand?

A checklist catches the obvious problems. Testing catches the ones you didn’t think to look for. The Launch Check covers the riskiest items on this list for $400, with plain-English findings, fixes you can paste into your AI tool, and a recheck once you’ve fixed them.