Website vulnerability scanner
See what a stranger can reach on your live site
Paste a URL. In about thirty seconds Prbl checks your deployed app for keys in the JavaScript, dashboards that render without a login, exposed environment files, weak security headers, and a database readable with the key you already ship to visitors. Read-only, no account, and every finding comes with the fix.
Why scan the live site, not just the code
Half of what goes wrong in a deployed app is not visible in the repository. The environment file that the host is serving. The Supabase table with row level security off. The dashboard that redirects to login in development and renders to everyone in production. You only see those by asking the running app, with no session, the way any visitor can.
We asked 4,740 live AI-built apps. 261 answered with something private: a rendered dashboard, a list of users from an API with no token, a readable database. Not one of those needed an exploit. The scanner runs the same checks on yours.
What the free scan checks
Loads the page and up to a dozen of its scripts and looks for Stripe live keys, AWS access keys, OpenAI and GitHub tokens, private keys, and a Supabase service_role key. These ship to every visitor.
Supabase anon keys, Firebase configs and Google AIza keys are meant to be public. They are flagged at medium with a verification step, because what matters is the configuration behind them, not the key.
Requests /dashboard, /admin, /account, /settings, /billing and similar with no session. Flags only when the response is the app's logged-in view rather than a redirect or a bare SPA shell.
Probes /.env, /.env.local, /.env.production and /.git/config. If the host serves them, every secret and the full source history are public.
Grades HSTS, Content-Security-Policy, X-Content-Type-Options, clickjacking protection, Referrer-Policy and Permissions-Policy, with a copy-ready value for each one missing.
Whether the app is reachable without TLS or fails to upgrade.
What owner verification unlocks
Two checks read real data to prove a finding, so they run only for the verified owner of the app, signed in, with a free account.
With the public Supabase key the app already ships, attempt a one-row read of common and discovered table names. Open table: the finding becomes high with proof. Row level security on: it downgrades to low.
Re-issue the /api and /rest endpoints discovered on your pages with no token. A JSON payload of real records is flagged, high when the path looks private (users, orders, me).
Both are read-only, one row at most, nothing stored. Free tools for single checks: Supabase RLS checker · exposed .env checker · security headers checker.
Then it fixes it
A live-site finding tells you what is exposed. The repo scan tells you which line caused it, and hands you a paste-ready prompt for your AI tool or, on paid plans, applies the fix with the rewriter and verifies the app still works. Connect the repo and the free GitHub Action keeps the next pull request from reintroducing it.
Prbl vs full DAST scanners
OWASP ZAP, Burp Suite, Intruder, Detectify and Acunetix crawl and fuzz an entire application. That is a different, heavier job. Here is the honest comparison.
| Prbl | Full DAST | |
|---|---|---|
| Approach | Passive surface check plus targeted probes, tuned to how AI-built apps fail | Crawl the whole app and fuzz every input |
| Time to result | About thirty seconds | Minutes to hours |
| Needs login or setup | No; owner verification unlocks the active checks | Usually configuration, sometimes authenticated crawling |
| Best at | Exposed keys, open routes, open databases, headers, exposed files | Injection across every parameter, session handling, business logic |
| After the finding | Plain-language explanation and the specific fix; the repo scan and rewriter pick up from there | A report |
| Cost | Free, no account | OWASP ZAP is free; commercial DAST is priced for security teams |
Frequently asked questions
What does a website vulnerability scanner do?
It examines a running site from the outside, the way an attacker or a search engine crawler would, and reports what is exposed: keys visible in the JavaScript, pages that should require login but do not, files the server should not be serving, missing security headers, and databases readable with the key the app already gives to visitors. Prbl's scanner is read-only and needs nothing but the URL.
Is it safe to run on my own site?
Yes. Every request is one a normal browser already makes, or a GET to a well-known path. The scanner never writes, never submits forms, never guesses passwords, and stores nothing the site returns. Secrets it finds are redacted in the output. The fetcher is built so it cannot be pointed at internal or private network addresses.
Is this a DAST tool?
It is a lighter, faster cousin. Full dynamic application security testing tools like OWASP ZAP or Burp Suite crawl every page and fuzz every input, which takes time and setup and finds a broader class of injection bugs. Prbl checks the surface where AI-built apps actually fail, in about thirty seconds, with no configuration. Many teams run both: Prbl on every deploy, a full DAST before a release.
How is this different from a malware or blacklist checker?
Tools like Sucuri SiteCheck look for malware, defacement and blacklist status on a site that may already be compromised. Prbl looks for the misconfigurations that let a compromise happen: the exposed key, the open dashboard, the readable database. They answer different questions.
My scan says my Supabase key is exposed. Is that bad?
The anon key is public by design, so on its own it is not a leak. It becomes serious when row level security is off on a table, because then anyone can read that table with the key from your page. The free scan flags it at medium; verifying you own the app unlocks the active check that tells you definitively whether any table is readable.
What did you find when you ran this on real apps?
We probed 4,740 deployed AI-built apps with the passive checks plus the open-route and open-data probes. 261 of them, about 1 in 18, served something private to a logged-out visitor: 159 rendered a private page, 72 returned records from an API with no auth, 30 had a database readable with the public key. The anonymised data is public.
Find out which side of the 1-in-18 your app is on. Thirty seconds, read-only, no account.
Scan my site →Guides: check if your Supabase database is exposed · is my Firebase database open? · the unprotected dashboard study · security headers guide · secret scanner · SAST for AI code