We just finished scanning 1,003 vibe-coded apps across Lovable, Bolt, Replit, Vercel, Streamlit, Heroku, and others. The Supabase RLS story is well-documented by now — 7.4% of Lovable apps and 6% of Bolt apps have tables wide open. But RLS accounted for 183 of our 190 CRITs. The other 7 came from finding classes that are arguably worse, because they're harder to detect and easier to exploit.
1. IDOR with PII leaks — health records accessible by incrementing an ID
Two Replit apps had Insecure Direct Object Reference (IDOR) vulnerabilities on their API endpoints:
roti-mami-booking.replit.app—GET /api/bookings/{id}returns any user's booking details (name, phone, email, appointment time) by iterating the numeric ID. No auth check.data-trade-marketplace-1-russellmxavier.replit.app—GET /api/privacy-health/{id}returns health-related records. The endpoint name alone tells you this shouldn't be public.
IDOR is consistently one of the top finding categories in real-world bug bounties (broken access control tops the OWASP Top 10 and HackerOne's annual reports) and it's the easiest to exploit: change /bookings/1 to /bookings/2. No tools, no Supabase knowledge, just a browser.
Why vibe-coded apps are especially vulnerable: AI code generators create CRUD endpoints with sequential IDs and no authorization middleware by default. The developer tests with their own data, sees it works, and deploys. They never test "what happens if I request someone else's ID" because the AI didn't generate that test either.
2. OpenAI project keys in public JS bundles — real money at risk
Two Bolt.host apps shipped live OpenAI sk-proj-* keys in their /assets/index-*.js bundles:
crypto.bolt.host— OpenAI project key in the Vite-built JS bundlesocial-media-content-6eme.bolt.host— same pattern
Both returned 403 at time of writing (possibly already taken down or access-restricted). But the pattern is widespread: our ai-js module flagged 38 apps across all platforms with hardcoded API keys in their JS bundles — 17 on Bolt.host (1 in 15), 18 on Vercel (1 in 4 of the AI-generated ones we scanned), and 3 others.
The risk is direct financial: anyone who extracts the key can make API calls on the owner's account. OpenAI bills per token. A single leaked key powering a GPT-4 loop can burn hundreds of dollars overnight before the owner notices.
3. Entire APIs with zero authentication
Two apps exposed their full OpenAPI spec with no security scheme defined on any endpoint:
chatbot-ai-mjs9.onrender.com— 7 public API endpoints, no authopenui.fly.dev— 12 public API endpoints, no auth
These aren't missing auth on one forgotten endpoint. The components.securitySchemes section of their OpenAPI spec is entirely empty. Every operation is callable by any HTTP client without a token, cookie, or API key.
This typically happens when a developer builds with FastAPI or Express, gets the API working locally, deploys it, and never adds the auth middleware because "I'll do that before launch." The AI assistant generates the routes but doesn't add Depends(get_current_user) unless specifically asked.
4. Private key material in production JS
veta-dashboard.herokuapp.com ships what appears to be private key material (PEM-format) inside its static JS bundle at /static/js/main.*.js. This is the kind of thing that happens when a .env file or a config object containing a private key gets bundled by Webpack/Vite because the build process doesn't distinguish "server-only" from "client-safe" variables.
The fix is usually one line in your bundler config — define: { 'process.env.PRIVATE_KEY': undefined } — but the developer has to know the key is leaking first. Most don't check their production bundle.
5. The hardcoded API key epidemic on Bolt.host
This deserves its own section. Our ai-js module analyzes the main JS bundle of every scanned app and flags hardcoded secrets. Across 251 Bolt.host apps:
- 17 of 251 Bolt.host apps (6.8%) had at least one hardcoded API key in the JS bundle
- 18 of 67 Vercel AI apps (26.9%) had the same — the highest rate of any platform
- Most common:
api_keypatterns (Supabase anon keys are expected and filtered out; these are other services) - Also found:
bearer_tokenvalues, service credentials, webhook secrets
The root cause: both Bolt.new and v0.dev generate frontend code that calls APIs directly from the browser. When the developer pastes their API key into the prompt ("use my OpenAI key sk-proj-..."), the generator embeds it in the client code. There's no server-side proxy step in the default templates.
Notably, Lovable had zero ai-js findings in this batch. Their code generator appears to route API calls through server-side endpoints by default — a meaningful architectural difference that keeps secrets out of the bundle.
What this means
Supabase RLS gets the headlines because it's the most common single finding class. But the real story from this 1,000-app scan is that vibe-coded apps have systemic security gaps across every layer: authentication (IDOR), secrets management (API keys in bundles), authorization (unauthed APIs), and data protection (RLS). No single fix addresses all of these.
The common thread: AI code generators optimize for "does it work?" not "is it safe?" The developer's prompt doesn't include "add auth middleware to every endpoint" or "never embed API keys client-side" because those aren't functional requirements. The resulting code works perfectly in a demo and fails catastrophically in production.
Scan your own app
Enter your URL at securityscanner.dev — the quick scan takes 10 seconds, no signup. For the full 50-module scan including IDOR probing, JS bundle analysis, and Supabase RLS audit: one free scan, no card.
Methodology
1,003 targets sourced from certificate transparency logs and Google search across 9 platforms. All scans read-only. Every CRIT finding was verified reproducible before disclosure. Disclosures sent to all identifiable owners before publication.
Full per-platform breakdown: Lovable vs Bolt vs Replit →
Aggregate stats: State of Vibe-Coded Security Q2 2026 →