Every founder who vibe-coded an MVP on Lovable, Replit, or Cursor believes their app is secure because it works. That belief is the single most expensive assumption in software right now, and I say that as someone who has watched it get expensive in real time, inside real client codebases, more times in the last 12 months than in the previous 5 years combined.
6 weeks ago, one of our senior engineers opened a funded startup's Supabase project as the first step of a routine audit, before we'd even scheduled the kickoff call properly. Inside 4 minutes, sitting in the browser's network tab in plain view, was a live service role key. Not a leaked key from a breach. A key the AI coding tool itself had wired directly into a client-side request, because that was the fastest way to make the demo work. The founder had shown that same app to investors the week before. The realization that stuck with me afterward wasn't about that one startup. It was that "it works" and "it's secure" had quietly become two completely different claims, and almost nobody building on these tools in 2026 has noticed the gap yet.
Why Vibe-Coded MVPs Are Suddenly a Board-Level Risk
The speed that makes Lovable, Replit, and Cursor genuinely useful is the same speed that removes the review gates a traditional build would have forced you through. A human engineer writing a Supabase integration by hand eventually asks, "wait, should this key be here?" An AI agent optimizing for "the login flow works" has no reason to ask that question unless it's explicitly told to, and almost no one tells it to, because almost no founder scoping a weekend prototype is thinking about Row-Level Security.
That gap didn't matter much when vibe-coded apps stayed internal demos. It matters enormously now that funded startups are shipping these same codebases straight to production, sometimes with real customer data, within weeks of the first prompt. We've audited pre-seed products with live payment data still running on the exact scaffolding an AI tool generated in its first session, never touched by a security review of any kind.
The Vulnerability Map Every Vibe-Coded App Shares
What Is Row-Level Security, and Why Do Inverted Policies Leak Data?
Row-Level Security (RLS) is a database-level access control feature, used heavily in Supabase and Postgres, that restricts which rows a given user can read or write based on a policy tied to their identity. An inverted or missing RLS policy leaks data by allowing any authenticated user, sometimes any anonymous request, to read or modify rows that belong to other users.
We see this constantly: a generated policy that reads USING (true) because the AI agent needed the query to return data during testing and never tightened it afterward, or a policy that checks the wrong column entirely, comparing a row's ID against the requesting user's ID instead of that row's actual owner field.
What Is a Supabase Service Role Key, and Why Shouldn't It Ship to the Browser?
A Supabase service role key is a credential that bypasses Row-Level Security entirely and grants full administrative access to a project's database. It should never reach a browser, mobile client, or any code path a user's device can inspect, because anyone who extracts it gains the same access as the project's own admin console.
Vibe-coding tools expose it constantly, and usually for the same reason: a client-side call needed elevated permissions to work during the first build session, and the fastest fix an agent can reach for is the key with no restrictions on it.
| A demo proves your app can work once, for you, on your data. It says nothing about what happens when a stranger points the same request at someone else's row. |
Inside a 72-Hour Diagnostic: How IndiaNIC Actually Runs This Audit
We built our diagnostic audit framework specifically for founders in this exact position, funded, live or near-live, and running on a codebase nobody has formally security-reviewed. It's deliberately compressed into 72 hours, because a four-week security consulting engagement is the wrong pace for a startup shipping features weekly.
The engagement usually starts with Jigar Panchal, IndiaNIC's Sales Director, who scopes which environment and data surfaces actually need review on the first call, so we're not auditing infrastructure that isn't live yet. Mihir Rawal, our Operations Director, then locks in the 72-hour window against the client's own release calendar, so the audit doesn't collide with a launch or a fundraising demo.
The technical work itself is split across two senior leads. Jay Shah, our Senior AI Tech Lead, drives the core diagnostic against the AI-generated codebase, tracing exactly how the vibe-coding tool wired authentication, database access, and API routes together. Kalpesh Gamit, a senior member of our technical team who has delivered several AI messaging and agentic AI projects involving MCP and multi-agent integrations, audits every agent-connected or MCP-wired endpoint separately, because those integrations tend to hide their own access-control gaps behind a layer the rest of the team never thinks to check.
Hour one is always the same: pull every environment variable and API key referenced anywhere in the codebase and check where each one is actually being called from, client or server. That single pass is what caught the exposed service role key in four minutes on the engagement I mentioned earlier. By the end of day one, we typically have a full map of every table's RLS policy, tested against at least two real, differently-permissioned accounts rather than trusted on the strength of the schema alone. Day two is remediation planning: not just what to fix, but in what order, because rotating a key before you've patched the route that leaked it just buys a few hours. Day three is verification, re-running the same exploit attempts that worked on day one to confirm they no longer do.
| The expensive mistake: Rotating an exposed key without first finding every place it leaked and every route it protected. One Series A client rotated their Supabase key the same day we flagged it, shipped the fix, and got hit again 9 days later through the exact same client-side call, now pointed at the new key. |
Your Pre-Launch Hardening Checklist: What to Fix Before You Scale
You don't need a formal audit to start closing the most common gaps today. Here is the sequence we'd run if it were our own product.
- Grep your entire codebase for the string "service_role" and any key that starts with your Supabase project's admin prefix. If it appears anywhere outside a server-only file, treat it as already compromised and rotate it.
- Pull up every table's RLS policy and test it with a second real account, not the admin account you built the app with. If that second account can read or write a row it shouldn't touch, the policy is inverted or missing.
- List every API route your app exposes, including ones you consider internal or debug-only, and confirm each has an explicit auth check. Vibe-coding tools generate routes faster than most teams remember to gate them.
- Audit storage bucket permissions directly in your provider's dashboard, not just in your application code. A bucket set to public during prototyping stays public until someone manually changes it.
- Search your git history, not just your current branch, for any key or secret that was ever committed. Deleting a file doesn't remove the secret from history; rotating the key does.
Frequently asked questions
What is the most common security flaw in apps built with Lovable, Replit, or Cursor?
The most common flaw is an exposed Supabase (or similar backend) service role key reachable from client-side code, followed closely by inverted or missing Row-Level Security policies that let one authenticated user read or modify another user's data.
How long does IndiaNIC's diagnostic audit take?
IndiaNIC's diagnostic audit framework runs on a fixed 72-hour timeline, split across environment and key discovery, RLS and route testing, remediation planning, and a final verification pass that re-runs the original exploit attempts to confirm they've been closed.
Can I check for these vulnerabilities myself before hiring an audit?
Yes. Searching your codebase for service role keys outside server-only files, testing RLS policies with a second real account, and reviewing storage bucket permissions directly in your provider's dashboard will surface most of the highest-severity issues without any formal audit.
If you've shipped an MVP on Lovable, Replit, or Cursor and haven't had anyone outside your own team look at how it handles authentication and data access, that's the conversation worth starting this week, before your next fundraising demo or your first real spike in signups. That's exactly the conversation Jigar Panchal's team is set up to have.
