Vibe coding security risks, and how to check your live app

You built an app with Lovable, Bolt, Replit, Cursor or v0, it works, and real people are starting to use it. Is it safe? Below are the seven vibe coding security risks we find most often in live apps, and how to check each one yourself in about 30 seconds.

Is vibe coding secure? The short answer

Vibe coding can produce a secure app, but not by default. AI builders are tuned to get you to a working demo fast, so the usual gaps are secret keys sitting in the browser, databases without access rules, and admin pages that only look locked. None of these show up while you test the app as yourself.

It isn't a rare problem. In May 2026, security firm Red Access reviewed about 380,000 public assets on vibe coding platforms and found roughly 5,000 apps built for business use. By its count, 40% of those were exposing sensitive data.

1. Secret keys in your browser code

What it is. Your app talks to paid services like OpenAI, Anthropic or Stripe using a secret key. If that key is in the code your site sends to every visitor, anyone can copy it and run up your bill or act on your account.

Why AI builders cause it. The fastest way to make a feature work is to call the API straight from the page. The AI often does exactly that, and puts the key right next to the call.

30-second self-check. Open your live site in Chrome, press F12, then Ctrl+Shift+F (Cmd+Option+F on a Mac) to search every file the page loaded. Search for sk-, sk_live and service_role. A Supabase anon key or Firebase config is meant to be public. Those three strings are not.

The fix. Move every call that needs a secret key into a server-side function (a Supabase Edge Function, a Netlify or Vercel function, or your builder's backend), store the key as an environment secret, and rotate any key that was ever public. Moving the code doesn't un-leak a key someone already copied.

Fix prompt: "Find every place this app uses a secret API key (OpenAI, Anthropic, Stripe secret key, any service_role key) in frontend code. Move those calls into server-side functions that read the key from an environment secret. List every key that was exposed so I can rotate it."

2. An open database

What it is. Most vibe-coded apps use Supabase or Firebase. Their public keys are designed to be visible, so the only thing stopping a stranger from reading your whole database is the access rules: row-level security (RLS) policies in Supabase, security rules in Firebase.

Why AI builders cause it. Tables get created fast, and access rules are easy to forget, especially on tables added later in the build. The worst version is when the app ships the service_role key, which skips every rule.

30-second self-check. Open your site in a private window without logging in. Press F12, open the Network tab and reload. Click any requests to supabase.co/rest/v1 or firestore.googleapis.com. If you can see rows that belong to other users, like every booking or every customer email, your database is open. One booking app we scanned was reading 13 tables straight from the browser, including its guest and inquiry tables.

The fix. Turn on RLS for every table, write policies so each user can only read and change their own rows, and never put the service_role key in frontend code. In Firebase, replace any rule that allows open reads or writes.

Fix prompt: "Enable row-level security on every Supabase table in this project. Write policies so logged-out users can only read data meant to be public, and logged-in users can only read and edit their own rows. Confirm the service_role key is not used in frontend code. Show me the final policies for each table."

3. Access checked only in the browser

What it is. Your admin page or paid area is protected by code that runs in the visitor's browser, like a check that says "if the user is an admin, show the dashboard." Anything that runs in the browser can be edited by the visitor.

Why AI builders cause it. Hiding a button or redirecting non-admins is the quickest way to make a page look protected. The AI does that and moves on, while the data behind the page stays reachable.

30-second self-check. In a private window, type your admin and dashboard addresses straight into the bar: /admin, /dashboard, /account. If the page loads, flashes content before redirecting, or pulls data in the Network tab, the lock is only cosmetic.

The fix. Check permissions on the server or in the database for every request that reads or changes protected data.

Fix prompt: "Find every page and action that should be limited to logged-in users or admins. Make sure the permission check happens on the server or in database policies, not only in frontend code. A logged-out user calling the API directly must get nothing back."

4. Public .env, .git and source map files

What it is. Files that should never be public sometimes are: a .env file full of keys, a .git folder with your full code history, or source map files (ending in .map) that let anyone download your original, readable code.

Why AI builders cause it. Many builders produce source maps by default to help with debugging, and exporting a project to your own hosting can carry across files the builder's hosting would have hidden.

30-second self-check. Visit yoursite.com/.env and yoursite.com/.git/config. You should get a not-found page, not a file. Then view the page source (Ctrl+U), click one of the .js file links, and add .map to the end of the address. If a file downloads, your readable source code is public.

The fix. Remove those files from what gets deployed, turn off production source maps (in Vite projects, set build.sourcemap to false), and rotate any key that was in an exposed file.

Fix prompt: "Make sure production builds do not publish source maps, .env files or the .git folder. Confirm nothing sensitive is copied into the deployed output, and tell me if any secret was in a file that may have been public."

5. Missing security headers

What it is. Security headers are instructions your server sends with each page, telling the browser what it's allowed to do. Without them, your site can be framed by someone else's page to trick users into clicking, and injected scripts meet fewer barriers.

Why AI builders cause it. Headers live in hosting settings, not in the app code the AI is working on, so they rarely get set.

30-second self-check. Press F12, open the Network tab, reload, click the first item (your page) and look at Response Headers. Look for Content-Security-Policy, Strict-Transport-Security and either X-Frame-Options or a frame-ancestors rule. If most are missing, your basic protections are off.

The fix. Add the headers in your host's settings (a _headers file on Netlify, the config on Vercel, or rules in Cloudflare), starting with HTTPS enforcement and framing protection, then a content security policy tested against your real pages.

Fix prompt: "Add security headers for this app's hosting: Strict-Transport-Security, X-Content-Type-Options, a Referrer-Policy, frame-ancestors or X-Frame-Options, and a Content-Security-Policy that allows only the domains this app uses. Tell me which file or setting they go in for my host."

6. No rate limits or bot protection

What it is. Nothing stops a bot from submitting your forms thousands of times, creating fake accounts, or hammering a feature that calls a paid AI API on your account.

Why AI builders cause it. A form that works once looks finished. Limits and bot checks only matter at scale, so they are usually left out.

30-second self-check. Submit your own contact or signup form five times in a row, quickly. If every attempt goes through with no challenge and no slowdown, a bot can do the same at thousands per minute.

The fix. Add rate limits to server functions and sign-up, put a bot check like Cloudflare Turnstile on public forms, and set spending caps with your AI and email providers so a runaway script can't run up an unlimited bill.

Fix prompt: "Add rate limiting to every server function and API route, especially sign-up, login, contact forms and anything that calls a paid AI API. Add Cloudflare Turnstile to public forms. List the limits you set."

7. Pages Google and AI can't read

What it is. Many vibe-coded apps send an almost empty page and build everything with JavaScript after it loads. Google can render JavaScript, but less reliably, and a Vercel study of crawler traffic found that the AI crawlers from OpenAI, Anthropic and Perplexity download JavaScript files without running them.

Why AI builders cause it. Single-page apps are the default output of most builders, and titles and proper not-found handling aren't part of "make the feature work."

30-second self-check. Press Ctrl+U on your homepage. If the body is mostly an empty div and script tags, crawlers that skip JavaScript see a blank page. Click through three pages and check whether the tab title changes. Then visit yoursite.com/this-page-does-not-exist and check its status in the Network tab: a 200 means search engines see a real page with no content.

The fix. Prerender or server-render your public pages, give every page its own title and description, and return a real 404 for missing pages. It's the same groundwork that makes fast websites win more customers.

Fix prompt: "Make every public page readable without JavaScript by prerendering or server-rendering it. Give each route its own title tag and meta description. Make unknown URLs return a real 404 status."

The vibe coding security checklist

Run these seven checks on your live app:

• Secret keys: no sk-, sk_live or service_role in your site's loaded files.
• Database rules: logged out, no request returns other users' rows.
• Server-side access: /admin and /dashboard show nothing when logged out.
• Public files: /.env, /.git/config and .map files all return not found.
• Security headers: Content-Security-Policy, Strict-Transport-Security and framing protection are present.
• Rate limits: repeated form submissions get slowed or challenged.
• Google readability: content in the page source, unique titles, a real 404 for missing pages.

What builder scans cover, and what they miss

Builders are adding their own checks, and they're worth using. Lovable runs a Quick scan when you open the publish dialog, covering database access rules (including row-level security mistakes) and dependencies, plus an optional Deep scan that reviews your code for exposed secrets and authorization gaps. Its own security documentation says findings don't block publishing by default and that you should still review your policies yourself.

What a builder scan can't give you is the outside view: what your deployed site exposes to a stranger, a bot or a search engine, including hosting headers and public files. Builders scan the project; nobody scans the deployed site. That's the gap we built the free vibe code check for. It checks your live app from the outside in about a minute.

An outside scan has limits too. It can't see your database rules from the inside, your server code or your login logic. When you need those reviewed by a person, our Security & SEO Audit covers them for $497, with a written report and a fix-or-rebuild call for each area.

FAQ

Is vibe coding safe?

It can be, but not automatically. The most common gaps, like exposed keys and missing database rules, come from building fast rather than bad intent. A vibe-coded app is as safe as the checks done before real users arrive.

Can AI write secure code?

Yes, when you ask for it specifically and check the result. Prompts that name the risk, like "enable row-level security on every table," usually work. The problem is that nobody asks until something leaks.

Do I need to rebuild my vibe-coded app?

Usually not. Most apps need the risky parts fixed in the right order: keys moved to the server, database rules turned on, protected pages enforced on the server. A rebuild only makes sense when patching would cost more than starting clean.

How do I know if my Supabase key is exposed?

Your Supabase anon key is meant to be public, and row-level security is what keeps your data safe. The key that must never be public is the service_role key. Search your site's loaded files for service_role. If it appears, rotate it in your Supabase dashboard right away and move whatever used it to a server-side function.

What does a vibe code security check cover?

An outside check looks at what anyone can see: secret keys in your JavaScript, database calls made from the browser, public source maps, security headers, speed, and whether search engines can read your pages. Your database rules and server code need a manual review.

Check your app today

Work through the checklist above, or run the free vibe code check on your live site and get the results in about a minute.