A Lovable app can ship the same class of security gaps as any fast-generated web app: API keys compiled into the frontend bundle, Supabase row-level security left off by default, missing security headers, and exposed source maps. Lovable is built for speed and works from natural-language prompts, so security hardening (the parts that don't show up as a visible bug during a demo) is easy to skip unless something explicitly checks for it.

A Bolt.new app is generated and deployed fast enough that security review is easy to skip entirely between prompt and production. The most common gaps are the same ones any rapidly scaffolded app ships: environment variables or API keys reachable in the compiled frontend bundle, no security headers set, and no verification that a backend's access rules match what the UI implies.

v0-generated apps are typically Next.js and React, which means they inherit the exact security defaults (or lack of them) that any hand-written Next.js app would have: no security headers unless you add them, and any secret referenced from client code ships to the browser. Because v0 is often used to scaffold a UI that's then wired to a real backend afterward, the biggest risk is usually in what gets connected after generation, not the generated code itself.

An app built primarily with Cursor carries the security posture of whatever code got accepted during AI-assisted edits. Cursor is very good at making code that runs, and has no default mechanism for flagging a hardcoded key, a missing header, or an overly permissive database rule, unless you explicitly prompt it to review for those things.

A Replit app, especially one built with Replit's Agent, can go from prompt to a publicly reachable URL in minutes, which means it's also publicly reachable before anyone has reviewed what got shipped. The most common exposure on Replit-hosted apps is secrets left in code or in a .env file that's served alongside the app instead of being excluded from the public deployment.

A Base44 app is generated and hosted end-to-end by the platform from a prompt, which means most of the traditional "did I configure this correctly" surface (hosting, headers, deployment) is handled for you, but data access rules, exposed integrations, and what the generated app reveals about its own structure are still worth checking, since those follow from what you asked the AI to build, not just where it's hosted.

Supabase is the backend behind a huge share of AI-generated apps, and its two riskiest defaults are easy to miss under a deadline: Row Level Security (RLS) ships disabled on every new table, and the anon key is meant to be public and sits in your frontend bundle by design, so any table without an explicit RLS policy is readable and writable by anyone who has your site open in a browser.

A Firebase project's client config (API key included) is meant to be public. That's not the risk. The real gap is Firestore, Realtime Database, and Storage security rules: Firebase's "test mode" starts every table wide open to any request for 30 days, and it's common for that permissive rule set to still be live long after the expiry date was meant to force a decision.

Vercel handles TLS, CDN caching, and infrastructure scaling, but it does not add application-level security headers, protect your API routes, or restrict preview deployments for you: those are configuration you (or your framework) have to set explicitly, and a fast prompt-to-deploy workflow rarely stops to add them.

Next.js is the framework underneath most AI-generated frontends, and by default it ships with no security headers, browser source maps enabled in production, and no built-in enforcement that a Server Action or API route actually checks who's calling it. All of that is left to explicit configuration the generated code doesn't always include.