Bolt scanner
A full stackbuilt in an afternoon
An app generated in the browser usually arrives with everything a real deployment needs: front end, API routes, a database, an integration key. The scan reads the whole thing from outside — the way a stranger reads it — and shows you what your own server answers to.
- No agent
- Reads the live URL
- 85 checks in every scan
Why this shape of app
Every layer
at once
The hard part of shipping a full stack is not writing it, it is that each layer has a configuration default and most of those defaults were chosen for the first developer, not the hundredth.
The API is open until told otherwise
A generated server exposes routes that answer to anyone: a collection endpoint that returns everything, a debug path left mounted, no limit on how often you may ask. The scan finds the paths your own JavaScript names and asks them anonymously — then reports what answered.
Keys end up on the wrong side
A secret the server needs and a secret the client needs look identical in an environment file. Prefix it with the name the framework reads at build time and it is compiled into a bundle the browser downloads. That is the check this app most often fails, and it is a rename plus a proxy.
The database has a public door
Supabase and Firebase both ship a client that talks to the database directly, with a key designed to be public and a policy layer that decides what it may read. The scan asks that door for row counts and for the rules on the paths — names and shapes only, never your rows.
Nothing is watching the traffic
A webhook that does not verify its signature is an endpoint anyone can call and pretend to be your payment provider. A redirect that follows a parameter wherever it points is a phishing link with your domain on it. Both are single-check findings, and both are common in code that was written to satisfy a demo.
What runs on your URL
The checks that
bite hardest here
A shortlist, not a special mode: paste a Bolt URL and the whole scan runs. These are the checks that most often have something to say about an app with its own server.
- Anonymous access to protected pages
- Exposed sensitive files
- Secrets in JavaScript
- Directory listing
- Open redirect through URL parameters
- GraphQL endpoint protection
- SQL injection in query parameters
- Tech stack & CVE
- Webhook signature verification
- Mobile API rate limiting
- Supabase row-level security
- Firebase security rules
Every one of these runs on every scan, whatever built your app. What each check looks at is on the full list.
The stack is not the risk. The unreviewed last mile is.
Stated plainly
What this page
is not claiming
There is no Bolt check in the scanner. No platform mode, no integration with the builder, nothing that reads your Bolt workspace. It is the same 85 checks that run on every site, pointed at the URL you paste.
Server-side code is invisible from outside. The scan can tell you that an endpoint answers without a limit and that a key is in the bundle; it cannot see the query behind the route or the secret that stayed in the env file. Those are a code review, and the repository scan is where that lives.
It is not a penetration test, and it will not load your app down. It never logs in, never submits anything of yours, never calls a state-changing endpoint, and refuses private and metadata addresses before a request leaves. The active checks run only on a domain you have proved you own.
A clean scan is a photograph, not a certificate. It is true of one URL on one day. The endpoint you add next week is exactly the kind of thing this list would catch — which is what the monitors are for.
How the scan runs
Three steps,
one URL
No agent to install, no DNS change, no access to your account. The scan reads the site the way a stranger does.
Step 1
Paste the URL you share
The deployment URL your visitors get, or your own domain once it points there. Nothing to install and no account to connect.
Step 2
It reads; it does not poke
One fetch of the page answers most of the list. Where a check has to make more requests there are budgets: a five-second cap per fetch, a small number of probes per scan, robots.txt obeyed throughout.
Step 3
Take the evidence and the prompt
Every finding carries what was measured — the path, the status code, the header — and a prompt written for the same agent that generated the app, so the fix is pasteable.
Ask your server
what it answers
Paste the URL and the whole list runs against it — the endpoints that answer to strangers, the keys in the bundle, the policies on the database. About a minute, and a free account.
Scan your site