Vibe-coded app security checklist before launch

A vibe-coded app can look finished before it is safe. The homepage loads, login works, Stripe checkout redirects, and the database has rows. That does not prove the app can survive real users, direct API calls, guessed IDs, failed payments, exposed keys, or one user trying to read another user's data.

This checklist is for founders who built with Lovable, Cursor, Bolt, Replit, v0, Claude Code, ChatGPT, or similar AI coding tools. It focuses on the launch-blocking security and business-logic checks that are easy to miss when the app was generated quickly.

Why vibe-coded apps leak data

AI coding tools optimize for getting the requested feature working. They are good at building the visible happy path, but they may leave security assumptions implicit. That is dangerous because production security is usually about what happens outside the happy path.

The common pattern is not a dramatic hacker trick. It is simpler:

• A page hides data in the UI, but the API still returns it.
• A Supabase table exists in an exposed schema without the right RLS policy.
• A service role key or backend secret reaches frontend code.
• A public storage bucket exposes files by predictable path.
• A Stripe payment succeeds, but the app writes access state incorrectly.
• An AI route can be called directly without auth, quota, or billing checks.

Step 1: Check public and private app visibility

Start with the basic exposure model. In many AI-built apps, the line between preview, public demo, staging, and production is blurry. A project can be publicly reachable before the founder realizes it.

Check:

• Public project URLs, preview URLs, shared demo links, and old deployments.
• Whether internal dashboards, admin pages, logs, or test data are indexed or linked.
• Whether generated source maps, debug routes, or build artifacts are public.
• Whether sample users, test credentials, or seeded records still exist.
• Whether the deployed app points to production services or a test project.

If a stranger can open an old preview and reach live auth, live database rows, or live payment flows, treat it as production exposure.

Step 2: Check auth and logged-out access

A login button is not the same as authorization. Test every private page and API route while logged out. Then test again as the wrong user.

1. Open private dashboard URLs in an incognito window.
2. Call private API routes without a session.
3. Call private API routes with a valid session for another user.
4. Try changing IDs in URLs and request bodies.
5. Try browser back/forward navigation after logout.
6. Try refreshing private pages after the session expires.

The app should fail closed. A private route should not return user data and then rely on the frontend to hide it.

Step 3: Check Supabase RLS

If the app uses Supabase, Row Level Security is one of the highest-risk launch checks. RLS must be enabled on private tables, but that is only the start. Policies must match the product's ownership model.

Run a practical table check:

select
  n.nspname as schema_name,
  c.relname as table_name,
  c.relrowsecurity as rls_enabled
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where c.relkind = 'r'
  and n.nspname = 'public'
order by c.relname;

Then inspect policies and test behavior. User A should not be able to read, list, update, delete, download, or overwrite User B's data through any UI, API, storage, RPC, or backend route.

For the deeper version, use the Supabase RLS checker for Lovable and Cursor apps.

Step 4: Check service role and API keys

Search the source code, deployed JavaScript, build output, source maps, logs, screenshots, issue comments, and Git history for secrets. Do not only check the current visible files.

Look for:

• service_role and SUPABASE_SERVICE_ROLE.
• sb_secret_ Supabase secret keys.
• OPENAI_API_KEY, ANTHROPIC_API_KEY, and provider tokens.
• STRIPE_SECRET_KEY and webhook signing secrets.
• Secrets stored in NEXT_PUBLIC_, VITE_, or PUBLIC_ variables.
• Keys pasted into prompts, README files, generated examples, or debugging output.

If a secret reached public code or public history, delete is not enough. Rotate the key, remove the exposure path, and check what the key could access.

Step 5: Check storage and file access

Database RLS does not automatically protect files. Supabase Storage, S3, Cloudflare R2, uploads, generated PDFs, images, exports, and signed URLs need their own checks.

1. User A uploads a private file.
2. User B tries to list the bucket, folder, or file index.
3. User B tries to open User A's file by URL or guessed path.
4. User B tries to overwrite or delete User A's file.
5. A logged-out visitor tries the same paths.
6. Signed URLs expire and are not reused as permanent public links.

Files are often where AI-built apps accidentally leak invoices, profile pictures, generated reports, transcripts, or uploaded documents.

Step 6: Check Stripe access after payment

Stripe checkout working is not the same as app access being correct. The launch risk is drift: Stripe says one thing, your database says another, and users get the wrong plan.

Test these events before launch:

• New subscription grants the right access to the right user or workspace.
• Failed payment does not leave paid features permanently open.
• Cancellation revokes or schedules access exactly as intended.
• Plan upgrade and downgrade update app limits.
• Webhook replay does not duplicate credits, seats, or usage.
• Webhook signature verification is enforced.

If your app uses Stripe and Supabase, paid feature checks should read from a trusted server-side source of truth, not a field the browser can change.

Step 7: Check AI API cost abuse

AI-built SaaS apps often connect to OpenAI, Anthropic, Replicate, ElevenLabs, vector databases, scraping APIs, enrichment APIs, or n8n workflows. These calls can cost money every time a route runs.

Check:

• Paid API calls do not run automatically on public page load.
• Expensive routes require auth and billing checks.
• Users have per-route, per-user, and per-workspace quotas.
• Retries have caps, backoff, timeouts, and idempotency.
• Refreshes and duplicate tabs reuse existing jobs instead of creating new ones.
• Provider caps, budget alerts, and a kill switch exist.

For the deeper version, use the AI SaaS API cost checklist.

Step 8: Check forms, mutations, and server-side validation

AI-generated apps often trust form fields because the UI only shows valid options. Users can edit requests in devtools, send curl requests, or replay old requests.

Before launch, try to submit:

• Another user's user_id, workspace_id, or organization_id.
• An admin role, paid plan, credit balance, or feature flag.
• Overlong text, HTML, scripts, empty required fields, and invalid enum values.
• Duplicate requests, old IDs, deleted records, and canceled subscription states.
• Requests from logged-out users and users with the wrong role.

Frontend validation improves UX. Server-side validation protects the business.

Step 9: Check admin and internal tools

Generated admin panels are especially risky because they often start as "temporary" tools. Temporary tools have a habit of surviving launch.

• Admin routes require a real server-side role check.
• Admin actions are logged with who did what and when.
• Support tools cannot impersonate users without a record.
• Internal search does not expose all users to any logged-in account.
• Bulk export, delete, refund, and credit-grant actions are restricted.

Step 10: Check monitoring and failure visibility

A launch checklist should include what happens after something breaks. If the app silently fails, you may not know until a customer emails or an API bill arrives.

Add at least basic visibility for:

• Auth errors and permission denials.
• Webhook failures and retries.
• Expensive API usage by user, route, provider, and job.
• Storage download or upload failures.
• Server errors, background job failures, and timeout spikes.
• Security-relevant admin actions.

Vibe-coded app security checklist

1. Old previews, demos, source maps, debug routes, and test data are not publicly exposed.
2. Private pages and API routes fail while logged out and as the wrong user.
3. Supabase private tables have RLS enabled and correct policies.
4. User A / User B isolation is tested for reads, lists, inserts, updates, deletes, files, and downloads.
5. Service role keys, Stripe secrets, AI provider keys, and webhook secrets are not in frontend code or public history.
6. Storage buckets and generated files are protected separately from database rows.
7. Stripe subscription, cancellation, failed-payment, and webhook replay behavior matches app access.
8. Paid AI API routes have auth, billing checks, quotas, retry caps, logging, and a kill switch.
9. Forms and mutations validate ownership, role, plan, enum values, and input size server-side.
10. Admin routes and support tools require server-side roles and leave audit logs.
11. Logs and alerts make launch failures visible before users pile up.

Launch verdict

Block ship if another user can access private data, a secret key is exposed, RLS is missing on private tables, Stripe access can drift into paid features, or paid AI APIs can be abused without limits.

Ship with fixes if core auth and data isolation pass, but storage, admin tools, monitoring, API cost controls, or webhook edge cases are incomplete.

Clear to ship when private data, files, secrets, payments, expensive routes, admin tools, and failure paths all pass the checks above.