A live-URL scan checks your app from the outside, the same way a visitor's browser sees it. You paste a URL, and it reads the page, the JavaScript bundles, and a few common paths. That is the whole input: what your app already serves publicly. Understanding that one fact tells you exactly what a URL scan is good at and where it goes blind, which is worth knowing before you trust any result, ours or anyone else's.
What it can find
Everything that leaks into what your app serves is fair game, and for AI-built apps that turns out to be a lot:
- Exposed secrets in the bundle — a Stripe secret key, an AWS key, an OpenAI key, or a private key that was never supposed to reach the browser.
- Backend-as-a-Service config — your Supabase or Firebase keys, which are public by design but only safe if the database rules behind them are set.
- Whether your database is actually readable — with the verified scan, using your own public key to check if an anonymous request gets data back, which is the difference between a theoretical and a proven exposure.
- Exposed files — a served
.envor.gitdirectory that leaks configuration. - Insecure transport — an app served over plain HTTP.
These are the highest-frequency real issues in AI-built apps, which is why a URL scan is genuinely useful despite only seeing the surface. We measured how often the database one shows up here.
Want to see exactly what Prbl flags? Watch it scan a demo app, no repo or account needed.
See a live scan →What it can't find
Anything that lives in code the browser never sees is invisible to a URL scan, and that includes some of the most serious issues:
- Missing authorization — a route that returns another user's data when you change an id lives in server code; the URL scan cannot see the check is missing.
- Injection — SQL or command injection is in how your server handles input, not in what it serves.
- Insecure defaults and logic flaws — a disabled TLS check, a permissive CORS setup, or broken business logic in your backend.
None of these appear in the bundle, so no honest URL scan will claim to find them. That is not a weakness to hide; it is the boundary of the method.
When to scan the source instead
Use a URL scan for the fast read on exposed secrets and an open database, especially when you have a deployed app but no public repo. When you want the deeper, code-level issues, scan the source: that is where authorization, injection, and insecure defaults show up. The two are complementary, and the review habit in this five-part pass covers what a URL scan structurally cannot.
Frequently asked questions
Do I need to give access to my app or code to run a URL scan?
No. A live-URL scan only reads what your app already serves publicly: its pages, its JavaScript bundles, and a few common paths. It is the same view any visitor's browser has. No login, no repo access, no agent installed. That is what makes it low-friction, and also what defines its limits, since it can only see what is already public.
Can a URL scan find every security issue in my app?
No, and any tool that claims to is overselling. A URL scan sees the outside of your app, so it is excellent at exposed secrets, misconfigurations, and whether your database is readable. It cannot see your server-side code, so it cannot find a missing authorization check, a SQL injection, or a logic flaw in code the browser never touches. For those, you scan the source.
What is the difference between the passive scan and the verified scan?
The passive scan reads your bundle and flags an exposed key or config. It does not touch your backend. The verified scan, which you unlock by proving you own the app, goes one step further and uses your public key exactly as a visitor could to check whether your database actually returns data to an anonymous request. That turns a 'you might have a problem' into a proven 'anyone can read this table.'
So when should I scan the repo instead of the URL?
Scan the URL for the fastest read on exposed secrets and an open database, especially when you have a deployed app but no public repo. Scan the source when you want the deeper, code-level issues: missing authorization, injection, insecure defaults, and the patterns that live in server code. They are complementary. The URL scan is the front door; the source scan is the full audit.
Try it on your app
The fastest way to see what a URL scan catches is to run one. Paste your live app URL or a public repo, and get the exposed keys, misconfigurations, and, for your own verified app, whether your database is readable. Run a free scan and see where your app stands.