Vibe coding security scanner: what a URL scan misses

You paste your app's address into a scanner, wait about twenty seconds, and a letter comes back. A, maybe C. Then the question that actually matters arrives: does this mean my app is fine?

Here is the part most tools in this category leave you to work out on your own. A vibe coding security scanner reads your app from the street. It sees what any visitor's browser sees, which turns out to be a great deal, and it stops at your front door. Whatever your server does in private stays private from the scanner too.

Knowing where that line falls is what makes a scan worth running. An A tells you the doors facing the street were shut when we looked, and it says nothing at all about the room behind them.

What is a vibe coding security scanner?

A tool that loads your live app the way a visitor would, then reads what came back.

You hand it a URL. It does not ask for your source code, your repository, your database password or an account on the builder you used. It fetches your page, lets the JavaScript run so it can see the code your app actually ships, reads the headers that came with the response, looks at your certificate, and asks your database and your file storage a few questions any stranger could ask.

Then it writes down what answered. That is the whole shape of it, and it is why this takes twenty seconds instead of a week.

The category exists because apps built with Lovable, Bolt, v0, Cursor, Replit, Windsurf and Base44 tend to go wrong in the same small number of places, and almost all of those places are visible from outside. A secret key in the bundle. A table that answers a stranger. A storage bucket that lists its own contents. Nobody needs your source to find any of them, because your app hands them to every visitor by design.

What a scan actually reads

Five surfaces, and your own visitors download four of them without noticing.

The bundle is the one that surprises people. Your app's code has to arrive in the browser before it can run there, so every key in it arrives too, along with the API paths it calls and often the names of the tables it reads. A scanner presses the same F12 a curious visitor would press. It is only faster, and it reads every file instead of the first one.

The database question is the one people expect to be invasive, and it is the tamest thing on the list. To find out whether a table is readable by strangers, ours asks the API for a count of the rows and reads the number off a response header. A count above zero means those rows are reachable. No row is ever fetched, and the key it asks with is the publishable one already sitting in your bundle, which is supposed to be there.

The four things a URL scan cannot see

Everything that happens on your server, because none of it is ever sent to a browser.

Your server code. Edge functions, API routes, database functions, anything running inside Supabase or on your host. A scanner can call an endpoint and read what comes back. It cannot read the code that produced it, so a mistake that only appears on certain inputs stays invisible.

Your environment variables. The keys you kept on the server, which is exactly where they belong. A scan can tell you it did not find a secret in your bundle. It cannot confirm that the secret is stored properly, because it never sees the place you stored it.

Your version history. A key you committed in March and removed in April is gone from your app and still sitting in your repository. Anyone who can see that repository can still read it, and no amount of looking at your live site will turn it up.

Your app's own logic. Whether one signed-in user can open another user's order by changing a number in the address. Whether a form will accept a price the browser sent it. These are decisions your app makes about what to allow, and catching them means signing in and trying things, which is a penetration test.

There is a fifth limit that belongs to us rather than to the category, and it is worth knowing before you read one of our reports. Supabase no longer serves the list of tables in a project to a publishable key, so a scanner has no way to ask what your tables are called. Ours works from three sources instead: the project index on older projects where it still answers, the table names it finds in your own bundle, and a list of twenty-six names that vibe-coded apps commonly use. An open table with an unusual name that never appears in your frontend code is one we will not reach. Supabase's own advisor will, which is the comparison two sections down.

Does a clean scan mean my app is secure?

No. It means every question the scan could ask from outside came back clean, and that is a smaller sentence than it sounds.

Part of the reason is the four blind spots above. The other part is that a check can end three ways and only one of them is a pass. A check finds something. A check asks and gets a clear no. Or a check gets no answer at all, because the request timed out, the host refused it, or the page never finished loading.

That third ending is the one that decides whether a report can be trusted, and it is the easiest to quietly round up into a tick. Ours prints "Couldn't check" on the line and leaves your grade alone. A false tick is the most damaging thing this scanner could put on a screen, because you would act on it.

The same honesty is what makes our own published numbers less alarming than they first look. Between 12 and 14 August 2026 we ran these checks over 30,998 live vibe-coded apps, and 99% of them came back with at least one finding. Nearly all of that is a single line: browser safety headers the hosting platform never sets, which most owners on a builder subdomain cannot switch on themselves. Counting it is correct. Reading 99% as "almost every app is in danger" is not.

URL scan, repo scan, or Supabase's own advisor?

They read three different things, so the useful question is which one can see the problem you have.

They overlap far less than the names suggest. Supabase's advisor scans your project and reports configuration problems, including tables with row-level security misconfigured. A URL scan reads the consequence, which is whether those rows are reaching strangers right now. The two come apart more often than you would expect, because switching the setting on is not the same as being protected.

A repository scanner is the only one of the three that can find the key you deleted last month. It is also the only one that cannot tell you whether the code it just read is the code you have deployed.

How to read the grade

The letter is capped by the worst single finding on the report, so a good score never rescues a serious one.

Every scan starts at 100. A critical finding costs 40 points, a high 15, a medium 5, a low 1. Then a ceiling sits over the arithmetic: one critical caps the grade at D, two cap it at F, and one high finding caps it at C. An otherwise tidy app with a single open table comes out a D, which is the intended behaviour.

Things you got right appear on the report and cost you nothing. Your publishable Supabase key sitting in your bundle is listed as correct, because that is what it is for, and painting it red is how a tool teaches you to ignore red.

What to do with a scan result

Our own free website security scanner runs nine read-only checks on any live URL in about twenty seconds, with no account. It reads, it never writes, and it never signs in.

If you would rather go through it by hand first, the 10-minute security checklist covers the same ground in the order worth doing it in.