AI app builders turned millions of non-engineers into software makers. Lovable alone reports around 8 million users and more than 200,000 new projects a day (TechCrunch). Many of those apps now hold real customer data, take real payments and run real processes.
The uncomfortable part: an app that works perfectly in the demo can still let any logged-in user read every other user’s data by changing one number in a request. Generators optimise for what you can see on screen. Security is invisible until it fails.
This guide gives you a practical audit checklist for apps built with Lovable, Bolt, Replit, Cursor and similar tools, explains where these apps typically break, how a short rescue audit runs, and how to decide between fixing, refactoring and rebuilding.
The scale of the problem in numbers
The evidence from 2025–2026 is consistent:
- 5,600 public apps scanned, 2,000+ serious vulnerabilities. Security firm Escape also found 400 exposed secrets and 175 cases of leaked personal data (SoftwareSeni).
- CVE-2025-48757: in 170 of 1,645 checked Lovable apps, data was exposed because row-level security was disabled (Cloud Security Alliance, The Next Web).
- The platforms are not immune either. In April 2026 a broken object-level authorization flaw in Lovable itself left other users’ code and database credentials accessible for 48 days (The Next Web).
- 406 million records were exposed by the app Chat & Ask AI because of a Firebase rule that allowed everything (CSA).
- About 55% of AI-generated code is secure in Veracode’s testing, and that rate has stayed flat as models improved (SoftwareSeni).
- 19.7% of packages suggested by models do not exist — a gift to attackers who register those names, a technique known as slopsquatting (CSA).
None of this means the tools are useless. It means a generated app is a first draft that has never met a security reviewer.
Where vibe-coded apps break: five recurring failure points
1. Database access rules
Many builders pair a front end with Supabase or Firebase. The browser talks to the database directly with a public key, which is fine by design — as long as access rules decide who may read and write each row. In Supabase that is Postgres Row Level Security (RLS); in Firebase it is security rules. If RLS is off on a table, or a rule says “allow read, write: if true”, the table is public to anyone who opens the browser console.
Typical findings: RLS enabled on the first tables but not on tables added later; policies that check “is logged in” instead of “owns this row”; storage buckets with uploaded documents set to public; the service-role key, which bypasses all rules, shipped to the browser.
2. Authorization in the API
Authentication answers “who are you?”. Authorization answers “are you allowed to touch this record?”. Generated code often does the first and forgets the second. The result is broken object-level authorization (BOLA): change /invoices/1042 to /invoices/1043 and you see someone else’s invoice. BOLA tops the OWASP API Security Top 10 for a reason.
A second pattern is security by hiding: the admin button is invisible for normal users, but the admin endpoint behind it does not check the role.
3. Secrets in the wrong place
API keys for model providers, payment secret keys and database credentials end up in the front-end bundle, in environment files committed to git, or in the system prompt of an AI feature. Removing a key from the latest commit is not enough — it stays in git history until rotated.
4. Dependencies nobody chose
Generated projects pull in dozens of packages. Some are outdated with known vulnerabilities; some, as the 19.7% figure shows, were invented by the model and may since have been registered by someone else. Without a lockfile and a dependency audit, nobody knows what actually runs in production.
5. Unguarded AI endpoints
If your app calls a language model, two new risks appear. Prompt injection: user-supplied text or uploaded documents contain instructions that override yours. Cost abuse: an endpoint without rate limits or budget caps lets anyone run up your model bill. We cover defences in detail in prompt injection and agent security.
The audit checklist: 24 points
Use the table as a working checklist. Severity reflects typical impact if the check fails.
| # | Area | What to check | Severity |
|---|---|---|---|
| 1 | Database | RLS (or equivalent rules) enabled on every table, including tables added later | Critical |
| 2 | Database | Policies check ownership or role, not just “authenticated” | Critical |
| 3 | Database | Separate policies for read, insert, update and delete | High |
| 4 | Storage | Buckets with user files are private; links are signed and expire | Critical |
| 5 | Keys | Service-role or admin keys exist only on the server | Critical |
| 6 | Authorization | Every API route and server function checks that the user may access the specific record | Critical |
| 7 | Authorization | Admin functions are protected on the server, not only hidden in the UI | Critical |
| 8 | Authentication | Password reset, email change and invite flows cannot be hijacked | High |
| 9 | Authentication | Sessions expire; tokens are not stored where scripts can read them without need | Medium |
| 10 | Secrets | Front-end bundle contains no secret keys (search the built JavaScript) | Critical |
| 11 | Secrets | Git history scanned; every exposed key rotated, not just deleted | Critical |
| 12 | Secrets | System prompts contain no keys, internal URLs or confidential rules | High |
| 13 | Dependencies | Every package exists, is maintained and is pinned in a lockfile | High |
| 14 | Dependencies | Known-vulnerability audit passes; a software bill of materials (SBOM) exists | Medium |
| 15 | Input | All input validated on the server; file uploads checked for type and size | High |
| 16 | AI | Model output treated as untrusted: never executed, never used directly in queries | High |
| 17 | AI | Rate limits and monthly budget caps on every model-calling endpoint | High |
| 18 | AI | Retrieved documents and user content separated from instructions; injection tests run | High |
| 19 | Web | HTTPS only, security headers set, CORS restricted to your own domains | Medium |
| 20 | Operations | Backups exist and a restore has actually been tested | High |
| 21 | Operations | Logs capture security events but no passwords, tokens or unnecessary personal data | Medium |
| 22 | Operations | Error monitoring and alerting reach a human | Medium |
| 23 | Privacy | Inventory of personal data, where it is stored and which providers process it (with DPAs) | High |
| 24 | Privacy | Users can export and delete their data; deletion really removes it | Medium |
The Cloud Security Alliance recommends a similar minimum for any AI-generated codebase: static analysis, dependency checks and secret scanning as mandatory CI steps; an audit of database access rules; a separate human review of authentication, API and data code; an SBOM; and verification that every suggested package really exists.
A 30-minute self-check before you call anyone
You can spot the most dangerous problems yourself, on your own app, before commissioning a full audit:
- Open the database dashboard (Supabase, Firebase or similar) and list every table and storage bucket. Note which ones have access rules switched on. Any table without them is a red flag.
- Search your built front end for secrets. Open the deployed site, view the JavaScript files in the browser’s developer tools and search for strings such as
sk_,secret,service_roleor your model provider’s key prefix. A public “anon” or “publishable” key is expected; a secret key is not. - Create two test accounts. Log in as the first, create a record, and copy its ID from the address bar or the network tab. Log in as the second and try to open that ID. If it loads, you have a BOLA problem.
- Try the admin pages as a normal user. Type the admin URL directly. If anything loads, protection is cosmetic.
- Check who can see uploaded files. Copy the link to an uploaded document and open it in a private browser window. If it opens without logging in, the bucket is public.
- Look at your model provider’s usage page. Unexplained spikes can mean someone found your AI endpoint.
If any of these checks fails, stop adding features and fix the basics first. If all of them pass, you still need the full checklist below — these six tests cover the loudest problems, not all of them.
How a 3–5-day rescue audit runs
Day 1: authorisation, access and inventory
First, the legal basics: written authorisation and verified ownership of the app, for example via a DNS record or a meta tag on the domain. Then read access to the repository, database, hosting and every third-party service. The output is an inventory: components, data stores, providers, user roles and the data each one touches.
Day 2: automated scans
Static analysis of the code, a dependency audit, a secret scan of the bundle and of the full git history, and an export of every database policy and storage rule. Automated tools find the obvious problems fast — and produce false positives that need human triage.
Day 3 (and 4 for larger apps): manual testing
This is where the critical findings usually come from. With two test accounts, the auditor tries to read and change the other account’s data through every endpoint and every table. Admin functions are called directly. AI endpoints are tested with injection payloads and with high request volumes.
Final day: report and critical fixes
Each finding gets a severity, a proof (request and response), the business impact in plain language and a fix. Critical items — public tables, exposed keys — are often fixed on the same day, keys are rotated, and the tests are re-run. The report ends with a fix plan and an estimate for everything else.
Fix, refactor or rebuild?
| What the audit shows | Decision | Typical effort |
|---|---|---|
| Sound data model; problems are missing rules, exposed keys, unprotected routes | Fix in place | Days |
| Data model acceptable, but business logic and checks live in the browser | Refactor: add a proper server or API layer | Weeks |
| Wrong data model, no tests, the same logic copied across screens, deep platform lock-in | Rebuild the core and migrate the data | Weeks to months |
Vendors quote rescue projects at $50–500k per app, but that range is unverified marketing data (Creatr). The real cost driver is how much of the data model has to change. Gartner is reported to expect that 75% of companies will face moderate or high technical debt from AI-generated code (Reptile.haus) — the earlier the audit, the cheaper the fix.
If you are about to build rather than repair, a structured sprint avoids most of these issues from the start; see building an MVP in 14 days.
If you find a breach
Treat an exposed table or key as an incident, not a to-do:
- Contain: enable access rules, revoke and rotate keys, disable the affected endpoint.
- Preserve evidence: keep logs before anything is overwritten.
- Assess: which data, how many people, for how long, and whether anyone accessed it.
- Notify if required: under the GDPR (Article 33), a personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people. Our guide on GDPR for AI chatbots covers the AI-specific parts.
Common mistakes
- Hiding instead of protecting. An invisible button is not access control.
- Fixing the tables you know about. New tables created next month will ship without RLS unless CI checks for it.
- Deleting keys instead of rotating them. A key in git history is still a leaked key.
- Trusting one scanner. Built-in platform checks are useful, but they do not test whether user A can read user B’s records.
- Asking the same tool to review its own work. AI review helps, but critical paths need a human who understands the business rules.
- Testing without permission. Even well-meant scanning of another company’s app can be illegal.
- Treating the audit as a one-off. Every new feature generated next week can reintroduce the same issues.
Conclusion
Vibe coding is a legitimate way to get a product in front of users fast. The risks are well documented and remarkably consistent: access rules, authorization, secrets, dependencies and AI endpoints. A focused audit finds the critical problems in days, and a handful of CI checks keeps them from returning. Ongoing monitoring after the fix belongs to AI Ops, not to good intentions.
If your app already holds customer data, it is worth knowing where you stand. Our Build team runs rescue audits and the fixes that follow. Book a free 15-minute audit call and we will tell you which checks to run first.