Guides

Security mistakes these builders ship.

Short, specific notes. No reviews and no invented scores.

• BoltBolt builds and keys left in the client bundleAnything Bolt inlines into the browser, including Vite client env vars, can be read by every visitor.
• CursorCursor app pre-launch security checklistEleven checks to run before you launch a Cursor-built app, each with a command or a setting to verify.
• FirebaseFirebase rules for apps shipped by a builderPublish rules before the app. Test mode and a true read rule make the database public to the internet.
• LovableLovable apps and Supabase row level securityLovable puts the Supabase anon key in the browser. Turn on row level security and never ship the service role key.
• ReplitReplit Secrets versus keys in the published appUse Replit Secrets for server code. Do not print them into HTML, client JavaScript, or a public .env.
• All platformsSecurity headers for AI-built apps: CSP, HSTS and X-Frame-OptionsAdd HSTS, a Content-Security-Policy, frame protection, nosniff and a referrer policy. Copy-paste config for Vercel, Netlify, Cloudflare and Next.js.
• SupabaseSupabase row level security for client-built appsEnable RLS, write policies that name who can see each row, and never put the service role key in the browser.
• SupabaseSupabase service_role key exposed in your frontend: what to doFind the key, rotate it, and move privileged calls into a server function. The anon key may be public. The service_role key never.
• v0v0, Next.js, and client-visible configIn a v0 app, a NEXT_PUBLIC variable is part of the browser bundle. Keep service keys in server components and route handlers.