Free security scanner for AI-built apps: what a URL scan can and can't tell you
A free scanner that only needs a URL is a genuinely useful first pass, and it is structurally unable to tell you the thing you probably actually want to know. Here's the honest line between the two.
What a passive, no-signup scan can and can't tell you
A scan that only needs your URL — no login, no keys — has to work entirely from what your app already shows a stranger: response headers, the JavaScript it ships to every visitor, whether a source map is publicly served, whether an API accepts requests from any origin. That’s real, useful information, and it’s honestly limited to what’s visible before anyone logs in.
Solacess’s own free Quick Scan is exactly this category, and says so: passive checks only — headers, exposed keys in your shipped JS, source maps, open CORS, debug routes left public. It cannot tell you whether one logged-in customer can read another’s data, or whether your Stripe webhook accepts a forged event, because neither of those is visible to someone who never logs in.
What “deep” or authenticated scanning adds, as a category
Across the industry, the meaningful jump in what a scanner can prove happens at the point it can actually act as a signed-in user — ideally two of them. That’s when a check stops being “this route’s shape looks risky” and becomes “I signed in as a second account and this route returned the first account’s data.” The same jump applies to payments: a scanner that can send a real (test-mode) webhook event can tell you whether your handler actually verifies it; one that only reads your code can only tell you whether it looks like you call a verification function somewhere.
| passive / URL-only | authenticated / two-account | |
|---|---|---|
| Needs from you | Nothing — just the URL | Domain ownership proof, two test logins, a test Stripe key |
| Can see | What any visitor sees, logged out | What a logged-in account can reach, and whether a second account can reach it too |
| Can prove an IDOR | No — requires a session | Yes, if it exists |
| Can prove a payment logic bug | No — requires sending an event | Yes, in test mode |
What's specific to Solacess in this category
- Two real accounts, not one. The two-account engine logs in as two separate test users and replays one’s requests as the other — the only way to actually prove a cross-account leak instead of inferring one.
- Stripe money-leak checks, not just “is Stripe installed.” Forged webhooks, replayed events, browser-trusted prices, and access kept after cancellation — all tried in Stripe test mode, not inferred from config.
- A dollar figure, not just a severity word. Every finding shows $ at risk based on what the check actually measured, so you can triage by cost, not by an abstract label.
The four passive checks a free scan can actually run
Try the free passive scan, then see what a full report adds.
The sample report is a real scan of a deliberately vulnerable app — nine findings, the proof behind each one, and what they would cost.