What is vibe coding and how do you secure a vibe-coded app?

What is vibe coding?

Vibe coding is a way of building apps where you describe what you want to an AI in plain language, accept the changes without reading the code and fix errors with more prompts. Andrej Karpathy coined the term in February 2025.

Simon Willison draws a simple line: vibe coding is building software with a model without reviewing the code it writes. If you read, test and understand the code, that is AI-assisted programming, not vibe coding. Willison considers vibe coding fine for low-stakes projects and warns against it where secrets, other people's data and API bills are involved.

The trouble starts when a vibe-coded prototype gets real users and their data. The app looks like it works, because the interface shows everyone only their own things. What can be reached by going around the interface is another matter.

Mistake 1: API keys in the browser

Anything in code loaded by the browser can be read by every visitor. The Gemini API documentation says it plainly: do not hardcode keys in web or mobile apps because they can be extracted, and call the API through your own server. A leaked AI key usually means a bill for someone else's requests.

Supabase has two kinds of keys. The publishable key may live in the browser because it only reaches what RLS policies allow. According to the Supabase documentation, the secret key (formerly service_role) bypasses every policy and must never be used in a browser or exposed to customers.

A typical leak path in Vite projects: a variable prefixed with VITE_ is bundled into the browser build. A secret key named that way is public. If you are not sure what a key or token is, you can identify it in your browser without sending it anywhere.

Mistake 2: Supabase tables without RLS

RLS (Row Level Security) is a set of database rules that decide which rows a given user can see and change. The Supabase documentation warns that a table in an exposed schema without RLS is readable and writable by any role granted access to it. The advice: enable RLS on every such table and test the policies instead of assuming they work.

CVE-2025-48757 shows what this looks like in practice. According to the reporters' statement of 29 May 2025, they analyzed 1,645 projects built with Lovable and found insufficient RLS policies in 170 of them (about 10%), exposing user data including email addresses and API keys. Lovable disputes the report, stating that each app's creator is responsible for protecting its data, and the NVD entry is tagged as disputed and has the status "Deferred", meaning NVD has postponed its analysis. Whoever is right in that dispute, the mechanism is the same: no policy means an open table.

Two traps that are easy to miss. A read policy says nothing about writes: check SELECT, INSERT, UPDATE and DELETE separately. Postgres views bypass RLS by default because they run with their creator's privileges, so a view over a protected table can hand out every row.

Mistake 3: public storage buckets

Files in Supabase live in buckets. A public bucket means anyone who knows a file's URL can download it without logging in. Access rules still guard uploading, deleting and moving, but not reading.

That is fine for product photos. It is not fine for invoices, contracts, ID scans or resumes. If file names are also predictable, such as sequential numbers, guessing URLs stops being guesswork. This and four other recurring mistakes are covered in five things that show up in apps built fast.

How Lovable protects API keys (including Google Gemini)

According to the Lovable AI documentation, the built-in AI features do not need your own Gemini key. Lovable creates a LOVABLE_API_KEY for each project, and model calls go through a server-side function, so the key and the prompts stay on the server. The exception is live voice conversations, where the browser streams audio directly to the model while the app's server starts the call and holds the key.

If you use your own key, for example from Google AI Studio, Lovable recommends storing it in Secrets and calling the API from an edge function. According to the documentation, Secrets are encrypted, injected into server-side functions and never reach the browser. Variables prefixed with VITE_ are a different thing: they are public by design, and Lovable will not store them in Secrets.

Lovable detects keys pasted into the chat and suggests moving them to Secrets. Before publishing it automatically runs a quick scan of database access rules, dependencies and MCP servers, and on request a deeper code review. Whether you can publish with open findings depends on workspace settings. The documentation notes that these tools cannot guarantee complete security.

What the tools do for you, and what they do not

They do more and more: keep keys server-side, remind you about RLS, scan dependencies for known vulnerabilities. That is real help.

What they do not know is what in your app belongs to whom. A scanner can check that a policy exists. It cannot check whether a team lead should see other teams' salaries, whether a customer can mark an order as paid, or whether an old test endpoint should still be live. Only someone who knows how the business is supposed to work knows that logic.

So a green scan means "no known problems found", not "safe". The same goes for every check, ours included.

Pre-launch checklist for a vibe-coded app

1. Search the code loaded by the browser (developer tools, sources tab) for keys. Only the publishable key may be there. 2. List every table and check that each has RLS enabled and separate policies for the four operations. 3. Log in as user A and try to read and change user B's data directly through the API, bypassing the interface. 4. Check which buckets are public and what is in them. 5. Check views and functions in the exposed schema. 6. List the routes that work without login and justify each one. 7. Run the tool's scan and read every finding, not just the critical ones. 8. Set spending limits on AI keys.

Keep in mind that checking the public site from outside (encryption, headers, who the site shares data with) does not test database rules. They are two different things. If you build apps for clients and want to do this systematically, see the builders page. How a buyer can assess an app is covered in how to check whether an app is safe.