Vibe Coding Puts APIs at the Center of AI App Security

API keys have become a weak spot in vibe coding

In late October, vibe coding was reaching new places. Epic Games said AI tools are writing much of the code for Unreal Engine 6 and Fortnite59. Google Play started letting people run private AI-built Android apps on their own phones6. Cloudflare released an open-source platform for managing apps that employees build with AI4. One of the less noticed items that month may matter just as much: Lovable said apps built on its platform can now use Perplexity web search without the builder needing a Perplexity account or API key2.

Across these stories, one thing keeps coming up. Most of the hard problems now sit where AI-built apps connect to other services, through APIs and the keys that unlock them. The tools for generating apps keep improving. The handling of credentials, request volume and access control has not kept up.

What happened

The clearest sign of the strain comes from The Atlantic, which reported on a flood of vibe-coded apps hitting app marketplaces. In a developer program update, a Strava community manager blamed "zero-code AI tools that produce apps that hammer APIs"1. Strava is a platform company with a public developer interface, and it is seeing a surge of third-party apps calling its services. Many were built by people who have never had to think about rate limits, caching or polite request patterns1.

The Atlantic also raised the question of upkeep. Dor Zvi, CEO of security firm Red Access, said that once users upload personal information or an app connects to real data, the creator becomes the whole security and support team for it1.

The platforms are starting to respond. Lovable's new "Managed by Lovable" option for its Perplexity connector bills searches to workspace credits, so builders never handle a key. The managed tier only covers Perplexity's Search API, though. Citations and deep research still need the builder's own key2. OpenAI made ChatGPT Sites generally available to Enterprise customers, with regional data residency, custom domains and private tunnels to internal APIs2. Replit now lets enterprises run its agent platform and published apps inside their own AWS, Azure or Google Cloud tenants2.

Why the key keeps leaking

The security record explains why platforms want to take credentials out of builders' hands. Different researchers keep finding the same failures, even though they use different methods.

The best-known case is still CVE-2025-48757. Replit engineer Matt Palmer was testing a LinkedIn profile generator built with Lovable. He removed an authorization header from a request and got back what looked like the platform's whole user database13. A broader scan of Lovable-built apps found about one in ten leaking user data through the same kind of flaw. The root cause was apps connecting to Supabase without row-level security policies13. Lovable disputes that the CVE is valid and puts the blame on users13. That disagreement matters later in this piece.

Later findings fit the same pattern. Wiz reported in February 2026 that Moltbook, a vibe-coded AI social network, exposed about 1.5 million API tokens through a Supabase database without row-level security12. Zuplo, an API-gateway company, also cites 35,000 exposed email addresses in the Moltbook case15. A January 2026 SupaExplorer scan of more than 20,000 indie vibe-coded launch URLs found about 11% exposing Supabase credentials in their frontend code12. Escape.tech scanned 5,600 deployed vibe-coded apps and reported more than 2,000 vulnerabilities and over 400 exposed secrets15. Wiz Research separately found exposed endpoints on Base44 that let anyone bypass authentication, including SSO on private apps, using only an app ID visible in the URL15.

One contributor on Reddit's r/vibecoding forum described an audit in which exposed API keys and secrets made up 73% of critical findings. These included Supabase service-role keys, Stripe secret keys and OpenAI or Anthropic keys shipped in client bundles11. That is a forum post, not a peer-reviewed study, but it matches the larger scans.

The costs go beyond data exposure. One reported case involved a developer whose vibe-coded site had exposed keys and open endpoints with no authentication or rate limits. Attackers used hundreds of dollars in API credits overnight15. Hosting provider Kodu points out that a leaked AI, SMS, email or cloud key can cause direct financial loss within minutes. Small teams often find out only when the invoice arrives16.

Where the sources agree, and where they don't

The diagnosis is nearly unanimous. Developer outlet XDA, consultancy Evil Martians, and security and gateway vendors all describe the same root problem. AI-generated apps treat the browser as the authority on what a user can see. The backend sends back everything, and the interface is trusted to filter it131917. XDA notes that popular AI app builders usually generate a frontend that talks directly to a hosted backend such as Firebase or Supabase, with a key built into the client. That design isn't dangerous on its own, but it becomes dangerous once access rules are missing13.

The main disagreement is about the cause. Some commentators blame the models directly. One widely shared essay argues that AI tools skip row-level security because it's the fastest way to a working demo14. Others push back. A guide from app builder Newly says AI doesn't write uniquely bad code; it just increases the number of apps going out without review12. Veracode's finding that 45% of AI-generated code samples across more than 100 models had vulnerabilities is often cited by both camps12. Lovable's position on the CVE is a third view: the platform did its part, and configuration is the user's job13.

The reading taken here is that the volume argument is the stronger one, and it also explains the platform moves listed above. The fixes for hardcoded secrets and missing server-side checks are old and well known: keep keys on the server, enforce access in the backend, limit what each key can do, and rotate leaked keys1219. What changed is who is shipping software. Many builders don't know these rules, so they can't ask the model to follow them17.

The vendor bias in this coverage also deserves a note. Many of the strongest warnings come from companies selling the fix, such as API gateways, secret scanners and security platforms152012. Their numbers line up with independent research from Wiz and others, so the problem looks real. Their claims about how easily their own products solve it should get more scrutiny.

The platforms are moving into the API layer

Read together, October's launches suggest the major platforms have accepted that hobbyist builders won't reliably manage secrets. So the platforms are increasingly doing it for them.

Lovable's managed Perplexity connector is the most direct example. If the builder never holds the key, the builder can't paste it into a React component2. Cloudflare's Void works at the organization level. It lets IT teams self-host a platform where employees deploy AI-built apps, while admins control who can deploy and access them, review logs, track resource use and set usage limits4. Cloudflare says its own internal instance is open only to employees, which by default prevents data leaks through vibe-coded apps4.

The New Stack's reporting points out the limits of that approach. Restricting who can open an app doesn't stop the app from pulling sensitive data or sending it somewhere else. Admins can also make new apps public by default, and Void's documented deployment process has no required security review before an app goes live4. Cloudflare's answer, that companies can modify the open-source platform themselves, puts responsibility back on the customer4.

Google takes a different route by limiting who an app reaches. Private Android apps built in Google AI Studio don't appear in Play search and are visible only to their creator, though they still have to follow Play policy. Sharing with trusted contacts is planned for later6. Fewer users means less exposure. It does nothing about how the app handles keys.

The New Stack also notes that agent access to APIs is a governance issue of its own. MCP gets agents into APIs, but it doesn't decide what they are allowed to see4.

What it means

Two trends are now meeting. Professional teams are adopting agentic coding seriously. Epic says engineers are "no longer writing the bulk of the code" while still steering architecture and performance, and it names Claude Code and Codex510. Meanwhile, non-engineers are shipping software that calls real APIs with real money and real personal data behind them115.

The Epic case and the Moltbook case aren't really about better or worse models. The difference is whether someone on the team understands the trust boundaries the code crosses.

The practical result is that API providers and app platforms are now the real security layer for vibe-coded software. Strava's complaint suggests API providers will tighten rate limits and app-review rules1. Builders like Lovable will likely keep absorbing credentials into managed, metered connectors2. That reduces the most common failure, but it also concentrates trust and billing in the platforms.

The gaps that remain are where future incidents are likely to come from: features still outside the managed tiers, internal apps that can be switched to public, and authorization logic that still lives in the browser.