Lovable, Bolt, and Cursor are great at turning ideas into working apps. The problem is that "working" and "safe" aren't the same thing. These tools optimize for getting something on screen quickly. Security is almost never part of that equation.
These seven patterns come up in audit work, in security research, and across developer communities. They're the predictable result of tools that ship development defaults and never prompt you to change them.
1. Authentication left open
This is the most common issue found in Lovable apps specifically. When Lovable generates Supabase edge functions, the default setting is verify_jwt=false. That means anyone on the internet can call your backend functions without logging in.
AI tools build great prototypes, but prototypes skip things like authentication checks. When you ship that prototype without verifying, you're running a live app with the defaults still on.
What this means for your users: Someone could create accounts, read private data, or trigger actions in your app without ever authenticating. If your app handles payments, they could potentially trigger transactions.
Open your Supabase edge functions and search for verify_jwt. If it's set to false, or missing entirely, your backend is wide open.
2. Secrets baked into your code
API keys, database passwords, and third-party tokens committed directly into your codebase. This shows up in apps built with all three tools. The AI generates code that hardcodes a key right in the file instead of pulling it from a secure environment variable.
Here's the part most people miss: even if you delete the key later, it's still in your git history. Anyone with access to your repository can scroll back through old commits and find it.
Exposed keys can give attackers access to your payment processor, email service, or database. A leaked Stripe key could let someone issue refunds or access customer payment details.
Search your codebase for strings that look like API keys: long random strings, anything starting with sk_, pk_, or key_. Check your git history too, not just the current files.
3. No data separation between users
This one is sneaky because the app looks like it works perfectly. Each user sees their own data when they log in. But under the hood, the only thing stopping User A from seeing User B's data is a number in the URL.
Change /dashboard/user/42 to /dashboard/user/43, and suddenly you're looking at someone else's account. This happens when the database doesn't enforce who can see what. It trusts whatever the browser asks for.
Any logged-in user can then access, modify, or delete other users' data. Medical records, financial info, private messages, whatever your app stores becomes accessible to everyone.
Look for database queries that filter by a user ID passed from the browser. If the database itself doesn't verify ownership (through row-level security or equivalent), the data isn't truly separated.
4. Security checks that only run in the browser
AI tools love putting logic in the frontend. It's the fastest way to make something work on screen. But when security checks run in JavaScript in the browser, users can bypass them using browser dev tools.
A common example: the app hides an "Admin" button using a JavaScript check like if (user.role === "admin"). But the actual admin API endpoints don't verify the role. Anyone who knows the endpoint URL can call it directly.
Features that should be restricted, like admin panels, data exports, and account management, become accessible to anyone who knows where to look. Hiding a button is not the same as securing a feature.
5. API keys with too much power
When an AI tool sets up a connection to Supabase, Stripe, or any third-party service, it typically grabs the most powerful key available. The one with full admin access. Even if the app only needs to read data, it's using a key that can read, write, and delete everything.
Supabase service_role keys show up in frontend code more often than you'd expect. This key bypasses all security rules entirely. It's meant for server-side admin tasks, not for code that runs in someone's browser. If it's in the frontend, an attacker has full admin access to your entire database: every record, every table, every account.
6. No limits on how fast someone can hit your app
Rate limiting means capping how many requests someone can make in a given time window. Without it, an attacker can try thousands of passwords per second, scrape your entire database, or run up your API bill by calling expensive endpoints in a loop.
AI tools almost never set up rate limiting. It's not the kind of thing that shows up in a demo. It's infrastructure work that only matters when bad actors show up. And they will.
Without rate limiting, password guessing attacks become trivial. And if your app uses a paid API (like OpenAI or a maps service), someone could rack up hundreds of dollars in charges in minutes.
7. APIs that accept anything you send them
When your app's backend doesn't check what it's receiving, it trusts that every request is well-intentioned. An API endpoint expecting a username could receive a database command instead. One expecting a number could receive a script.
AI tools focus on the happy path: what happens when a normal user does normal things. They rarely generate the validation code that handles what happens when someone deliberately sends bad data.
What this means for your users: Attackers can inject malicious data, corrupt your database, or trick your app into running code it shouldn't. In the worst case, they can steal data from other users or take over accounts.
These aren't edge cases
A typical AI-built app has three to five of these issues at once. That's not because the people building them are doing something wrong. The tools are optimized for speed, not safety. They ship development defaults, settings that make sense while you're building, but that need to be changed before real users show up.
Most of these are fixable. Some are quick changes, others take more work. But the first step is the same: figure out which ones affect your app.
AI coding tools are a good starting point. But "it works" is not the same as "it's ready for users." Before you launch, get a second pair of eyes on the security basics.