The five-line pick
You built the app with an AI agent, it works, and you have no idea whether a stranger can read your users' data.
Don't read a 40-point checklist. Paste the prompt below into the coding agent you already use.
It checks the four things that sink small apps: database row access, secret keys in the browser, fake Stripe webhooks, and unmetered AI calls.
It ends with SHIP or NO-SHIP and the exact files to fix.
Run it before every launch and after any big change your agent makes.
Give this to your agent
You are auditing this repository before it ships. Do not change any code yet. Report only.
Check these four areas. For each, list what you checked, the files and lines, and PASS / FAIL / NOT APPLICABLE.
1. Database row access (Supabase or any Postgres exposed to the browser)
- Every table reachable from the client has Row Level Security enabled.
- Every table with RLS has policies that limit rows to the signed-in user (or the correct role). A table with RLS on but a policy like "true" for everyone is a FAIL.
- Storage buckets holding user files are not public unless that is intended.
2. Secrets in the client bundle
- Search for API keys, the Supabase service_role key, Stripe secret keys (sk_live_, sk_test_), OpenAI/Anthropic/other AI keys, and database URLs.
- Any secret in a browser-exposed variable (NEXT_PUBLIC_*, VITE_*, EXPO_PUBLIC_*, REACT_APP_*) or in client-side code is a FAIL.
- Check that .env files are in .gitignore and that no secret appears in git history (git log -p | grep for key prefixes).
3. Stripe webhooks
- The webhook endpoint verifies the Stripe-Signature header with the webhook signing secret (for example stripe.webhooks.constructEvent) using the raw request body.
- Orders, credits or plan upgrades are granted only from verified webhook events, never from a client redirect or query string.
4. Paid AI endpoints
- Every server route that calls a paid AI API requires a signed-in user.
- Each route has a per-user or per-IP rate limit, and there is a spending cap or usage counter.
- The AI key is only used server-side.
Finish with:
VERDICT: SHIP or NO-SHIP
If NO-SHIP, list each FAIL in priority order with the file to change and a one-line fix. Then ask me before fixing anything.
What each check catches, in plain words
- Row access. Supabase lets the browser talk to your database directly. Row Level Security is what stops user A from reading user B's rows. If it's off, anyone with your public key can query the table.
- Secrets in the browser. Frameworks ship any variable with a public prefix to every visitor. A secret key there is a public key.
- Stripe webhooks. Anyone can send a fake "payment succeeded" request to your endpoint. Checking Stripe's signature is how you know it really came from Stripe.
- Paid AI endpoints. An open route that calls an AI model lets a stranger run up your bill. Sign-in plus a rate limit closes that.
Before you pick an agent to run this
Any coding agent that can read your repo can run the prompt. If you haven't chosen one, start with AI coding agents for solo builders.
Sources
- Supabase Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security
- Supabase API keys (service_role must stay server-side): https://supabase.com/docs/guides/api/api-keys
- Next.js environment variables (NEXT_PUBLIC_ is sent to the browser): https://nextjs.org/docs/app/guides/environment-variables
- Vite env variables (VITE_ is exposed to client code): https://vite.dev/guide/env-and-mode
- Stripe webhook signature verification: https://docs.stripe.com/webhooks#verify-events
- Bookmarked post that started this: https://x.com/PrajwalTomar_/status/2080993986127524251
No affiliate links. No prices or benchmarks on this page.