security checks for vibe-coded apps

Your app works.
Is it leaking?

VibeProtect checks the app you built with Lovable, Replit, Bolt or Cursor, and the code behind it. It finds leaked keys and database rules that let anyone in, then hands you a prompt that fixes each one, written for your builder.

Free for one app. No card, no install.

Example: VibeProtect reading the JavaScript that myapp.lovable.app sends to every visitor, and flagging an OpenAI key in it and the OpenAI SDK set to run in the browser.
works with apps built on

what we find

The holes AI builders leave, said in plain words.

AI builders are great at making things work. They are less careful about who else can use what they made. These are the common ones, and the ones we check for.

Your OpenAI key is in your JavaScript

Anything your app's code holds, every visitor downloads. A key in there is a key anyone can copy and spend.

live app: leaked API keys in the bundle

Your AI SDK runs in the browser

Builders sometimes flip a setting literally named dangerouslyAllowBrowser. It hands your AI key to every visitor.

live app: AI SDK called from the browser

Your Supabase master key is public

The service_role key ignores every access rule. In front-end code it means anyone can read, change or delete all of your data.

live app + repo: service_role key in browser code

A table shipped without rules

Your Supabase anon key is meant to be public. Row Level Security is what stops it reading everything. We read your migrations and flag every table that never turned it on.

repo: Supabase migrations without RLS

Your Firebase rules say "anyone"

Rules left in test mode let anyone on the internet read or write your data without signing in. We read the rules files in your repo.

repo: open Firebase rules files

There is a password in your GitHub repo

Keys pasted into code, or a whole .env file, get synced to GitHub along with everything else. We find them and tell you which to rotate.

repo: committed secrets and .env files

A package you use has a known hole

Your app runs on hundreds of open source packages. We look up the exact versions you have and tell you what to bump.

repo: vulnerable dependencies (OSV.dev)

Any website can act as your users

Server code that lets any site call your API with your users' cookies attached. A page they visit somewhere else could read their data.

repo: CORS open to any origin with credentials
Every check, explained →

Headers, HTTPS, forms and the rest, each in one plain sentence.

the fix is a prompt

You built it by prompting. You can fix it the same way.

Every finding comes with a prompt worded for the builder that made your app. Paste it in, let it make the change, rescan. No security course required.

highsecrets.openai-key

OpenAI API key exposed in your public JavaScript

Anyone who visits your app can read your OpenAI key in the JavaScript their browser downloads. Whoever copies it can use it on your bill.

key
sk-proj-Ab…9xQ
found in
/assets/index-4f2a9c1b.js
used by
new OpenAI({ dangerouslyAllowBrowser: true })

Step one is yours: revoke the key in your OpenAI dashboard and make a new one. Deleting it from the code does not un-leak it.

Paste into Lovable click to select

Security fix: my OpenAI API key is in the front-end code, so anyone visiting the site can copy it.
Move the OpenAI call into a Supabase Edge Function, store the new key as a Supabase secret named OPENAI_API_KEY, and have the front end call that function instead.
Remove the key from every front-end file and from any VITE_ environment variable. Do not change the UI.

then rescan to confirm it is gone

how it works

Four steps, mostly copy and paste.

  1. 01

    Paste your app's address

    The URL it is live at. We tell which builder made it from the address and the code.

    myapp.lovable.app
  2. 02

    Ask your builder to verify it

    We give you a prompt. Your builder adds a tiny file to prove the app is yours.

    /.well-known/vibeprotect.txt
  3. 03

    Scan

    You get a grade and a short list, worst first, in plain language.

    2 findings · grade D
  4. 04

    Paste the fix prompt

    Copy the prompt for each finding into your builder, then rescan to see it go green.

    > Paste into Lovable

the rule we do not bend

We only scan apps you prove you own.

A scanner that checks any URL you type is a tool for snooping on other people's apps. So before the first scan, you show us the app is yours, and we re-check that every night.

  • The exact address, nothing else. Verifying myapp.lovable.app covers that app, not anything else on lovable.app.
  • Read-only, always. No logins, no attack traffic, no writes. We read what any visitor's browser already gets.
  • Repos through GitHub only. We read code only from repos you installed our GitHub App on, and never run it.
  • We say who we are. Our scanner identifies itself as VibeProtect-Scanner/1.0 (+https://vibeprotect.dev/scanner).
A small fileany app

Your builder adds it to the public folder.

https://myapp.lovable.app/.well-known/vibeprotect.txt
A meta tagany app

One line in the head of your home page.

<meta name="vibeprotect-verification" content="vibeprotect-verify=...">
A DNS recordcustom domains

A TXT record, if you have your own domain.

_vibeprotect.app.example.com TXT "vibeprotect-verify=..."

pricing

Free to find out. Cheap to keep watching.

Free

$0/month
no card needed

Check one live app for API keys leaked into the code your visitors download.

Builder

$12/month
billed monthly

For your side projects: scan the code too, and get told when a new prompt breaks something.

Pro

$29/month
billed monthly

For people shipping for real: daily rescans, and your AI agent can scan and fix on its own.

questions

Fair questions.

Is it safe to scan my app?

Yes. We read what any visitor could already read: your pages, the JavaScript they load, your headers and your HTTPS setup. We never try to log in, guess passwords, send attack traffic or write anything. And we only scan an app after you prove it is yours. The repo scan reads your code through our GitHub App and never runs it.

Do you store my data or my keys?

We never store secret values or anything from your database. When we find a key we keep a redacted version (like sk-proj-Ab…9xQ), enough for you to know which key to rotate and not enough to use it, plus the file and line where it was. We never read rows from your database at all. Your repo is read for the scan and not kept afterwards.

How is this different from Lovable's built-in security scan?

Use both. Lovable's check looks at your project from the inside, while you build. VibeProtect looks at the published app from the outside, the way a stranger would (what is in the JavaScript you actually shipped, how the site is served), and scans the GitHub repo Lovable syncs to for committed secrets, vulnerable packages and Supabase migrations without RLS. It works the same way for apps from Replit, Bolt, v0 or Cursor.

Does it work if I don't use GitHub?

Yes. The live app scan only needs your app's address. It finds leaked keys in your JavaScript, AI SDKs running in the browser, and problems with headers, HTTPS and forms. Connecting GitHub (on paid plans) adds the repo scan: committed secrets, vulnerable packages, Supabase migrations without RLS, Firebase rules files and risky code. If your app uses Supabase or Firebase, the repo scan is where its access rules get checked.

I don't really know what RLS or an SDK is. Is that a problem?

Not at all. Every finding starts with what it means for you, and comes with a prompt you paste into the builder that made your app. It knows what RLS is, so you do not have to.

Why do I have to verify my app?

Because we will not scan an app for someone who does not own it. Verifying takes one prompt: we give you the exact words, your builder adds a small file or tag, and you are done. See how verification works.

Check your app before someone else does.

One app is free, no card. The hardest part is asking your builder to add a file.