The main security risks of AI-generated code are secret keys left where anyone can read them, databases with no access rules, users who can open other people's records by changing an ID, unchecked input, fake or outdated packages, weak login handling, no limits on requests, sensitive data in logs and no working backups. Tools like Cursor, Lovable, Bolt, Replit, v0, Claude and ChatGPT write code that runs well in a demo. They don't know which of your data must stay private, and unless someone asks for these protections, they often leave them out.
Below, for founders who built an app with AI and the developers who look after it, is each problem with what it can cost and how it's fixed.
Why AI-built apps share the same weak spots
An AI coding tool is judged on one thing while you work with it, which is whether the feature appears and behaves as asked. A page that shows every customer's invoices to anyone looks exactly like a page that shows each customer only their own.
Research points the same way. In Veracode's 2025 GenAI Code Security Report, more than 100 language models completed 80 coding tasks, and about 45% of the results contained a known type of security flaw. A Stanford study from 2022 found that developers using an AI assistant wrote less secure code than those without one, and were more likely to believe their code was secure. In 2025, a researcher scanned 1,645 apps from Lovable's public showcase and found 170 whose databases could be read or changed by anyone, because access rules were missing (recorded as CVE-2025-48757).
So the code these tools produce needs the same review you'd give a new developer's work.
Nine common problems in AI-generated code
1. API keys and secrets in the front end or a public repository
A secret key is a password your app uses to talk to other services, such as payments, email, an AI model or your database. If it sits in code that runs in the visitor's browser, or in a public GitHub repository, anyone can copy it.
It happens because the quickest way to make an integration work is to paste the key straight into the code, and that's what the tool does when you ask it to connect Stripe or OpenAI. GitGuardian counted 23.8 million secrets leaked on public GitHub in 2024, and found higher leak rates in repositories that use AI assistants.
// Runs in the browser: anyone can read this key
const supabase = createClient(SUPABASE_URL, "eyJhbGciOi...service_role...");
const openai = new OpenAI({ apiKey: "sk-proj-...", dangerouslyAllowBrowser: true });What it can cost: a stolen AI or cloud key can run up thousands of dollars in charges overnight, and a database key with full rights hands over all your data. The fix: keep secret keys on the server only, in environment variables or a secrets manager, never in the repository. Any key that has ever been exposed must be revoked and replaced, because deleting it from the code doesn't remove it from the history.
2. Database access rules turned off or left open
Supabase and Firebase let the browser talk to the database directly, which is safe only when the database itself decides who may read and write each row. In Supabase this is called Row Level Security (RLS). In Firebase it's the security rules.
AI tools create tables quickly and often leave RLS off, or add a policy that allows everything so the app stops showing errors. Firebase projects are sometimes started in test mode and never locked down. In July 2025, the Tea dating-safety app exposed around 72,000 images, including ID photos, from storage that had no access controls. The company denied that AI wrote the code, and the storage was open either way.
// Firebase rules that let anyone read and write everything
allow read, write: if true;
-- Supabase: switch RLS on and let users see only their own rows
alter table invoices enable row level security;
create policy "own invoices" on invoices
for select using (auth.uid() = user_id);What it can cost: a full copy of your customer data in someone else's hands, a breach you may be legally required to report, and the trust of every user. The fix: turn on access rules for every table and storage bucket, write a policy for each kind of user, then test them while signed in as an ordinary user and while signed out.
3. Users reading other users' data by changing an ID
This is called broken access control, and it's at the top of the OWASP Top 10 list of web risks. A signed-in user opens /invoices/1042, changes it to /invoices/1043 and sees another company's invoice.
The AI tool checks that the user is logged in, because you asked for a login, and skips checking that the record belongs to them because nobody said so.
// Any logged-in user can read any invoice
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
res.json(await Invoice.findById(req.params.id));
});
// Safer: only return the invoice if it belongs to this user's company
const invoice = await Invoice.findOne({ _id: req.params.id, companyId: req.user.companyId });
if (!invoice) return res.status(404).end();What it can cost: one curious customer, or a competitor with a free account, can walk through your entire database one number at a time. The fix: check ownership on the server for every request that reads, changes or deletes data, including admin actions, file downloads and exports.
4. Trusting what users type
Every form field, search box and URL parameter is a way into your app. Without checks, a user can send text that the database runs as a command (SQL or NoSQL injection) or that the browser runs as a script for other visitors (cross-site scripting, XSS).
AI tools often build database queries by gluing strings together, and they reach for innerHTML or dangerouslySetInnerHTML when you ask for rich text or formatted messages.
// Injection: the search text becomes part of the SQL command
db.query("SELECT * FROM users WHERE email = '" + req.body.email + "'");
// Safer: a parameterized query
db.query("SELECT * FROM users WHERE email = $1", [req.body.email]);What it can cost: stolen or deleted data, accounts taken over through a script hidden in a comment or profile, and your site used to attack your own customers. The fix: use parameterized queries or a well-used ORM, validate input on the server against the format you expect, and let the framework escape output instead of inserting raw HTML. A related JavaScript problem, where user data changes how all objects behave, is explained in our article on prototype pollution.
5. Outdated or made-up packages
AI tools suggest open-source packages from memory, so they sometimes pick versions with known vulnerabilities, or invent a name that sounds right and doesn't exist.
Researchers from three US universities studied 576,000 code samples from 16 models and found that about 20% of the packages they recommended didn't exist. Attackers can register those invented names and fill them with malware, a trick called slopsquatting.
What it can cost: malicious code running inside your app or on your developer's laptop, with access to everything both can reach. The fix: check every new package before installing it (who publishes it, how long it has existed, how many people use it), commit the lock file, and run a dependency audit such as npm audit or GitHub's Dependabot on a schedule.
6. Login and session mistakes
Typical AI-generated mistakes in login code include passwords stored with weak hashing or none, login tokens kept in the browser's local storage where any injected script can read them, sessions that never expire, password-reset links that can be guessed or reused, and admin checks done only in the front end, where a user can switch them off.
What it can cost: account takeover, including administrator accounts. The fix: use a proven authentication service or library instead of a hand-built one, keep sessions in secure, HTTP-only cookies with a sensible expiry, and repeat every permission check on the server.
7. No limits on requests
Without rate limiting, nothing stops a script from trying thousands of passwords a minute, creating fake accounts, scraping your catalog or calling your AI feature until the bill explodes. AI tools rarely add limits unless asked, because the app works fine without them during testing.
What it can cost: broken-into accounts, a large invoice from your AI or SMS provider, and a site that slows down for real customers. The fix: limit requests per user and per IP address on login, sign-up, password reset and any endpoint that costs you money, and set spending caps with each provider.
8. Secrets and personal data in logs
When something breaks, the AI's first move is often to add a line that prints the whole request or user object. Those lines stay in production and send passwords, tokens, card details or health data into log files, error trackers and third-party monitoring tools that many people can read.
console.log("Login attempt", req.body); // includes the passwordWhat it can cost: a data leak through a tool nobody thought of as sensitive, and a possible breach of privacy laws such as the GDPR. The fix: remove debug output before release, log only the fields you need, and mask passwords, tokens and personal data in any logging setup.
9. Missing or untested backups
Backups are a security control too. In July 2025, SaaStr founder Jason Lemkin reported that Replit's AI agent deleted his production database during a code freeze. There was no automatic backup to restore, and a bad migration or a ransomware attack can do the same damage.
What it can cost: lost orders, lost customer records and days of downtime. The fix: keep production data apart from development and testing, give AI agents no direct write access to production, run automatic backups stored away from the main system, and restore one on a schedule to prove it works.
When vibe coding is safe enough
Vibe coding, building an app by describing it to an AI tool, is a fast way to test an idea. A prototype with fake data and a handful of test users carries little risk. The picture changes once the app holds real customer data, takes payments, connects to your business systems or is open to the public. From that point, the questions in this article need answers backed by evidence, from someone other than the tool that wrote the code.
If you aren't technical, you can still ask your developer, or your AI tool, a few direct questions. Where are our secret keys stored? Is every database table protected by access rules? What stops a user from opening another customer's record? When did we last restore a backup? Vague answers are a sign the work hasn't been done yet.
Frequently asked questions
Is AI-generated code less secure than code written by people?
Studies measure it differently, but they agree it often contains well-known flaws. Veracode found known flaws in about 45% of the code produced in its 2025 tests, so review AI-written code as carefully as code from a new hire.
Is Lovable or Supabase itself insecure?
The platforms provide the tools to secure your data, such as Supabase Row Level Security. The problems come from apps where those rules were never switched on or were written to allow everything. Lovable added a security scan after the 2025 findings, but a scan doesn't replace checking your own access rules.
Can I ask the AI tool to fix the security problems itself?
It helps once you know what to ask for. The same tool missed the problem the first time, though, and it can report a fix that covers only part of it, so test each fix by trying to break it.
What should I do if a secret key has already been exposed?
Revoke the key with the provider and create a new one right away, then check the provider's logs and billing for use you don't recognize. Removing the key from the code isn't enough, because it stays in the repository history and may already have been copied.
How do I know if my AI-built app is safe to launch?
Have someone independent test it before real users and real data arrive, and ask for evidence behind each problem they find so your team can confirm and fix it.
Get your app checked before your users find the gaps
If your business runs on an app built with AI, an outside review costs far less than a breach. Our AI code assessment looks at any application, whatever tool or stack it was built with, and checks its security, code quality, maintainability and readiness for production. We sign an NDA before we see your code. You get a report with evidence for every finding and a clear order for what to fix first. Assessments start from $1,000. To find out what yours would cover, book a free 30-minute call.