This article is part of our AI-Built Site Rescue hub. Want help applying it? Talk to eSEOspace.
The failures worth checking first in an AI-built app are open data, exposed keys, missing access checks and unverified payments. Mixed-up environments, poor crawlability and no exit plan come next.
We don't rank them by frequency, because no source we opened measures how often they happen on real business sites. This guide is part of our AI-Built Site Rescue hub, and was checked against vendor documentation and published research on 9 November 2026.
AI is a fine way to build. The problem is software that reaches production without review, whoever wrote it. Disclosure: eSEOspace builds with AI tools, including Claude Code, and sells services around them.
Key Takeaways
- Open database tables and exposed keys are documented risks in the tools AI-built apps rely on.
- Vite publishes variables prefixed
VITE_to the browser by design. - Stripe says unverified webhooks can let an attacker fake events that trigger fulfillment.
- Research shows AI-assisted code can introduce real flaws, but the main dataset does not compare AI and human defect rates.
- Some builders' exports do not move your app off their platform.
- Only test apps you own or have written permission to test. eSEOspace does not do penetration testing.
What the research does and doesn't say
Start with what we can't claim. No source we opened shows that AI-built sites are less safe than hand-written ones.
Georgia Tech's Vibe Security Radar lists 310 published CVEs and GitHub advisories traced to AI-assisted code changes, with data through 26 September 2026. CVEs are publicly catalogued security flaws. The largest category it lists is authentication and access control, with 90 findings.
Read that with its warnings. The radar's method page is candid. "This is not a census of every AI bug and does not compare AI and human defect rates." The radar's home page also notes "Only 4%–18% of each month's advisories have been researched so far, so a short bar can mean little research rather than few AI-caused vulnerabilities."
Claude accounts for 81% of findings that name a tool. The radar cautions: "A findings share above the commit share is an upper bound, not proof a tool writes worse code." We disclose that number because we sell Claude Code services.
Failure 1: Database tables anyone can read
Some builders connect the browser directly to a hosted database, which is fine when the rules are right. Without those rules, data is exposed.
Supabase's RLS guide is direct. "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." RLS, or row-level security, is the database rule that limits each user to their own rows.
Check: open Supabase's Security Advisor and read every warning. Our row-level security guide walks through it.
Failure 2: Secret keys in the browser
Frontend tools publish some settings to the browser on purpose. A secret placed in one of those settings is public.
Vite's docs are direct. "VITE_* variables should not contain sensitive information such as API keys."
Check: search your own code for secret key prefixes. If one is exposed, rotate it.
Failure 3: Permission checks only in the browser
Hiding a button doesn't protect the data behind it. OWASP's A01 page gives an example of an app with all its access control in the front end. Anyone can skip that with a direct request.
Check: sign in as a second test user on your own app, and try to open the first user's records. Our broken access control guide has the full test.
Failure 4: Payment events nobody verifies
A payment integration can work perfectly in a demo and still be open to fakes. The demo never sends a forged event.
Stripe's webhook guide explains the risk. "Without verification, an attacker could send fake webhook events to your endpoint to trigger actions like fulfilling orders, granting account access, or modifying records."
Generated handlers can also miss the less obvious rules. Stripe says the same event can arrive more than once, and that it doesn't guarantee event order.
Check: use our Stripe checklist in a sandbox.
Failure 5: Development and production mixed together
An AI tool making changes while you build is useful. The same tool touching live customer data is a different matter.
Replit's docs state "Agent is not able to modify the production database." They also say legacy setups shared one database, which meant development changes could affect live apps. Other tools behave differently.
Check: confirm that your live app uses a separate database, and know which tools can write to it.
Failure 6: Pages search engines and AI tools can't read
This one has changed, so old advice may be wrong. "AI-built sites can't be crawled" is no longer a safe claim.
Lovable's SEO docs say apps created from May 13, 2026 (June 22, 2026 on Enterprise plans) use server-side rendering. Older React and Vite apps are pre-rendered for verified crawlers when they request a page.
Google's JavaScript SEO guide says "Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page." It still recommends server-side or pre-rendering, partly because not all bots can run JavaScript.
Check: ask your tool's docs how your app renders. Our guide to JavaScript rendering and AI crawlers goes further. No fix guarantees rankings.
Failure 7: No way out
Exporting code doesn't always mean you can leave. This surprises owners late.
Base44's developer docs are clear. "The exported code still relies on Base44 to run, so a ZIP is a copy of your code, not a way to move your app off Base44." They add "Your secrets and app users aren't included."
Tools differ, so read your builder's export page before you need it.
Check: find out what an export includes, and what you'd have to rebuild.
How to use this list
Fix in this order: data, keys, access checks, payments. Those are where a mistake reaches customers or money. Then deal with environments, crawlability and your exit plan.
Only test apps you own or have written permission to test. Don't run scanners against other people's sites, even out of curiosity. eSEOspace does not do penetration testing.
Next step
Pick the first three failures and check them this week. If you want outside help, our website security consulting covers assessments of your setup and vendors. It reduces risk, but it cannot certify an app as safe.
Frequently asked questions
Are AI-built apps less secure than hand-coded apps?
No source we opened establishes that for real sites. The Georgia Tech radar says it doesn't compare AI and human defect rates. What matters is whether someone reviewed the app.
What's the first thing to check?
Your database rules. Supabase says a table in an exposed schema without row-level security is readable and writable by any role with a grant on it.
Can AI tools fix these problems?
They can help write fixes. A person still needs to confirm the rules match your business, because the tool doesn't know who should see what.
Do AI-built sites show up on Google?
They can. Google says Googlebot queues pages with a 200 status for rendering, and some tools now render on the server. Check how your tool works, since behavior changed in 2026.
Can I test whether another company's AI-built app has these flaws?
No. Only test systems you own or have written permission to test. Unauthorized testing can create legal exposure.
Do you offer penetration testing?
No. eSEOspace does not do penetration testing. If you need one, hire a qualified firm.
