Everything you need to take your AI-built app from prototype to production. Database, auth, security, domains, AI context — interactive guides with progress tracking, platform-specific instructions, and copy-paste code. Built for people who ship with Lovable, Bolt, Cursor, and Next.js — not security engineers.
The single most important thing on this page. Every step takes minutes. Skipping any of them is the difference between a clean weekend and a 3am rotation of every credential you own.
11 checks that cover every bug class we see in real breaches of AI-built apps. Each one ships with a one-liner you can paste into a terminal or your DevTools to confirm it passes.
Any `sk_live_*`, `sk-*`, or `AKIA*` key shipping in your bundle will be drained within hours of launch. Anything with "secret" in the name belongs server-side only. Rotate anything you find.
service_role bypasses every RLS policy you wrote. It must never appear in a `NEXT_PUBLIC_` variable, a client component, or anywhere shipped to the browser. If it ever has, rotate it now.
Git remembers everything. If a `.env` ever landed in a commit — even one you deleted later — assume every secret it held is public. If the command below returns anything, rotate every credential inside it.
Your Supabase URL and anon key are meant to ship to the browser — RLS is what actually protects the data behind them. Without it, anyone who knows your project URL can query every row. Any `false` in the result below is a wide-open table.
Every query must use parameter binding — your ORM's placeholders, prepared statements, or the Supabase query builder. Template literals inside `.query()` or `.raw()` with a variable inside are the giveaway.
Maintain an allowlist of public paths and require a session everywhere else. Pick a logged-in API route, strip the session cookie, and re-request it — if it still returns data, your middleware isn't running where you think it does.
For every endpoint that fetches by ID, the database query must also filter by the authenticated user. Create two accounts, grab an ID as User A, then request it as User B — if the data comes back, you have an IDOR.
Without it, bots flood you with fake accounts within hours of going live. Supabase: Dashboard → Authentication → Settings → enable "Confirm email". Clerk and Auth.js have the equivalent toggle.
Your handler must validate the `Stripe-Signature` header before trusting the payload — otherwise anyone can POST a fake `checkout.session.completed` and unlock paid features for free. If the test below returns 200, the check is missing.
Every one of these is a potential XSS vector. Grep your codebase, and for each hit either switch to plain-text rendering or pipe the input through DOMPurify first.
Add `Strict-Transport-Security`, `Content-Security-Policy`, `X-Frame-Options`, and `Referrer-Policy` in your hosting config. For authenticated endpoints, replace `Access-Control-Allow-Origin: *` with your real origin.
The bugs are the same, but every platform ships its own defaults, footguns, and workarounds. Pick yours.
RLS, anon keys, and the policies your AI never wrote.
170+ Lovable apps were exposed via the same bug. Here's the fix.
What Bolt scaffolds, what it skips, and what to add before launch.
Editor-side risks: prompt injection, MCP, and what your IDE can leak.
Middleware, server actions, and the bypasses that ship with templates.
Your AI's tool calls are an attack surface. Lock them down.
You scanned. You found something. Each card is a one-screen fix recipe — what's broken, what to do, and the walkthrough that proves it.
Bug · Tables are exposed via the anon key with no row-level filtering.
Fix · Enable RLS, then write `auth.uid() = user_id` policies for every table.
Bug · Routes return any record by ID without ownership checks.
Fix · Add `where user_id = auth.uid()` to every query that takes an ID.
Bug · Service keys, Stripe keys, or OpenAI keys ended up in client bundles.
Fix · Move them to server-only env, rotate them, and re-deploy.
Bug · `dangerouslySetInnerHTML` renders untrusted HTML directly.
Fix · Render as text, or sanitize with DOMPurify before injecting.
Bug · String-concatenated SQL queries built from user input.
Fix · Use parameter binding or your ORM's query builder. Never concatenate.
Bug · Mass assignment on signup lets anyone register as admin.
Fix · Allowlist fields on the server. Never spread `req.body` into a user record.
Bug · OTP verification is client-checked or skippable via response tampering.
Fix · Verify on the server, lock the account state, and rate-limit attempts.
Bug · The "upgrade plan" call accepts the new tier from the client.
Fix · Always derive plan state from your billing provider webhook, never from the request.
Reference material, conceptual framing, and longer reads — for when you have a coffee and want to actually understand what you just shipped.
Database, auth, hosting — every step from demo to deployed. Interactive checklist with platform-specific instructions.
Project rules, docs, and prompt techniques that make AI ship better code. Templates for Cursor, Claude Code, and Lovable.
The canonical security list, rewritten for people who ship with Lovable and Bolt.
IDOR, RLS, XSS, SSRF, SQLi — 30+ security terms in plain English.
How the same BaaS default shipped to production in Moltbook, Tea, Cal AI, and Quittr.
What can your agent actually destroy? A framework for thinking about damage.
Lockfiles, audits, and the 39-minute window that mattered. Practical hardening.
The handoff problem in AI development, and how to close the loop.
The questions we get most from builders shipping AI-generated apps. Each answer also lives in the page schema so AI search engines can quote it directly.
Start with the Prototype to Production guide on this page. The four biggest gaps between a prototype and a production app are: database (migrate off SQLite or in-memory storage to Supabase or Neon), authentication (use a real auth provider instead of custom JWT logic), environment variables (audit every secret, remove any from client-side code), and hosting (deploy to Vercel, Railway, or Netlify with a custom domain). Our step-by-step guide walks through all of these with platform-specific instructions.
Start with the pre-launch checklist on this page, or use the interactive Security Hardening guide. They walk through the checks that catch over 90% of the bugs we find in AI-built apps: enabling Row Level Security on every Supabase table, moving the service_role key off the client, testing for IDOR, verifying API auth enforcement, checking webhook signatures, and setting security headers. Each step links to a deeper guide.
Row Level Security (RLS) is the PostgreSQL feature Supabase uses as its primary access control mechanism. When RLS is enabled on a table, every query is filtered by policies you write — for example "users can only see rows where user_id matches auth.uid()". Without RLS, the anon key (which is meant to be public) gives full read and write access to your entire database. In our scan of 100 vibe-coded apps, 68% of Supabase-backed apps had missing or broken RLS. See the Supabase playbook in the platforms section above for the fix.
Yes — but only if Row Level Security is enabled on every table and the policies are correct. The anon key is designed to live in your client JavaScript. Its safety depends entirely on RLS doing its job. The service_role key is the opposite: it bypasses all RLS and must never appear in client code, NEXT_PUBLIC_ environment variables, or your bundled JavaScript.
IDOR (Insecure Direct Object Reference) is the most common bug in AI-generated APIs. It happens when a route like GET /api/orders/{id} returns the order without checking that the authenticated user actually owns it. To fix it, add a where-clause that filters by the current user — for example WHERE user_id = auth.uid() — to every query that takes an ID. The fix recipes section above links to a full walkthrough.
The OWASP Top 10 is the security industry's canonical list of the most critical web application security risks, maintained by the Open Worldwide Application Security Project. It applies one-for-one to AI-built apps — the bugs are exactly the same, AI just ships them faster. We wrote a builder-friendly version at /owasp-top-10 that explains each category in plain English with the actual code your AI ships and how to fix it.
Create a project rules file (.cursorrules for Cursor, CLAUDE.md for Claude Code, or a prompt preamble for Lovable/Bolt). In it, define your exact tech stack with versions, your folder structure, your security rules (enable RLS, never expose service_role, parameterize queries), and include example code patterns. The AI Context Mastery guide on this page walks through every step with templates you can copy-paste. The biggest single improvement: build features incrementally instead of all at once.
No. These guides are written specifically for builders shipping with AI tools — Lovable, Bolt, Cursor, v0, Replit, Claude — not for security professionals. Every recipe is one screen long, every checklist item takes minutes, and every guide assumes you're a creator or founder, not a penetration tester.
Every claim on this page is grounded in standards, official docs, or named CVEs. If you want the source material, here it is.
Last reviewed and updated 7 April 2026 · Maintained by the Flowpatrol Team
Reading the field manual is half of it. The other half is proving your app actually does what the checklist says. Paste a URL.