A security researcher scanned 1,764 apps built with Lovable, Bolt, and similar AI coding tools. The results should not surprise anyone who has watched a non-technical founder ship an AI-generated prototype to production in a single afternoon.

Seven percent of the apps had Supabase databases with row-level security turned off. Not configured wrong. Off. Any authenticated user could read or modify every row in the database. Fifteen percent of Bolt-generated apps shipped hardcoded API keys in client-side JavaScript. That includes Stripe keys, Supabase service keys, and at least one OpenAI API key with a billing account attached.

These are not obscure edge cases. These are apps that people connect to real payment systems and real user data.

The findings come from a Q2 2026 report by securityscanner.dev, which automated the scan across apps deployed through the major AI coding platforms. The numbers are specific to the sample, but the pattern is broader.

This is not an AI problem. It is a deployment problem that AI made faster.

The pipeline runs something like this: a user types a prompt, the model generates a working UI with a database connection, and the result looks impressive in the browser. The model optimizes for visual correctness because that is what the user can immediately verify. It does not optimize for row-level security on Supabase because RLS syntax is nontrivial and getting it right requires context that reaches beyond the prompt window.

The builder then hits deploy. The app goes live. Stripe takes payments. The database sits open.

That sequence is new in scale but not in kind. Several commenters on the r/netsec thread compared it to the PHP era, when MySQL queries with direct string interpolation landed on production servers because the language lowered the barrier to entry faster than it raised the barrier to doing it safely. History does not quite repeat. It compiles.

The thread also surfaced a more pointed observation: the current crop of AI builders creates code that looks senior-level in structure but junior-level in security. A Login endpoint generates fine. Role checks on every database query do not. Admin-only API endpoints get exposed because the model did not reason about permissions across a session. The code reads cleanly. The architecture does not exist.

One commenter noted that basic fuzzing with different user roles catches roughly 80 percent of the authorization failures in these apps. A simple run of any API security scanner would flag the hardcoded keys in seconds. Neither step happens. The pipeline is prompt, build, ship, and only then maybe think about what just went live.

The report carries an implicit question about where the tool developers fit into this. Lovable, Bolt, Cursor, Copilot, Replit Agent: each tool's onboarding flow emphasizes speed. None ships with a prominent security-check gate. The default behavior is to generate a working prototype, not to warn the user that the generated database has no access controls. For some tools, the prototype is directly deployable, and the user never sees the gap between "it looked fine in preview" and "it has an unauthenticated API endpoint exposing customer data."

That leaves platform companies in an uncomfortable position. The security failures happen inside apps built with their tools. The app developers are not security engineers; many of them would not recognize a Supabase RLS policy if one were printed on the packaging. But the generated code bears the structural signatures of AI coding assistants: the model's tendency to build the happy path and skip every unhappy path that real systems must harden.

There are no reported breaches in the report. That could mean none happened. It could also mean that searching for open Supabase databases built with Lovable is not a high-effort task, and the discovery phase has different incentives than the reporting phase.

For builders using these tools, one takeaway is straightforward: if you generated a database-backed app with an AI tool and did not manually inspect the authentication layer, assume something is exposed. A second: if you deployed a Bolt app and never checked for hardcoded keys in client-side code, assume a key is leaking. Neither assumption is alarmist. They follow directly from the incidence rates in the audit.

The wider story is not that AI tools create insecure code. Many do. The wider story is that the deployment distance between "impressive demo" and "production infrastructure" has shrunk to a single afternoon, and the security tooling has not kept pace. For app builders, that distance has gotten much shorter than the check-everything-before-you-ship instinct would like it to be.

We got here before, more slowly. The PHP era gave us SQL injection as a cultural rite of passage. The AI coding era looks poised to give us open databases as the default. The lesson is less about the code and more about who pays attention between the demo and the deploy.

Sources