Is your paid app leaking data or money?
$ solacess scan democart --deep
We log in as two different customers and try to break your app the way a real attacker would. Every finding carries the request that proved it, a dollar figure, and a fix you paste back into Cursor.
No account needed · the free Quick Scan reads only what your site already shows every visitor
- domain verified
- two sessions established
- S2 service_role key in bundle
- A1 account B read A’s invoices
GET /api/invoices/inv_8f2c as: account-B → 200 OK "owner": "account-A" "customer_email": "a•••@•••.com"
real scan · our own deliberately vulnerable test app
built for apps shipped with lovable · bolt · cursor · replit · v0 · claude code — on next.js, supabase and stripe, with real customers paying
What this actually is
you point at your app
One DNS record proves it is yours. Two test logins you made yourself. That is the whole setup.
we log in as two customers
Then we ask for A’s data while signed in as B. If it comes back, the bug is proved, not guessed.
you get proof and a price
The request that did it, what it costs you a month, and a prompt you paste into Cursor to fix it.
Your AI wrote the code. Nobody reviewed it.
what the AI gave you
- A working app, in a weekend
- Tables created without row-level rules
- A webhook handler that trusts whatever arrives
- Access checks written in the browser, not the server
- Keys pasted where they were convenient
what solacess gives back
- The exact request that leaked the data
- The table anyone can read, named
- The forged payment your app accepted
- The dollars a month you are losing, with the basis
- A fix prompt you paste back into Cursor
Twenty-four checks. Each one has to prove itself.
Grouped by what goes wrong, not by jargon. The ones marked two accounts need a second test login — that is where the findings other scanners miss live.
data leak
11- S1API keys sitting in your JavaScript bundle
- S2The Supabase key that bypasses every rule
- D1Tables anyone can read without logging in
- D3Users who can promote themselves to admin
- A1One customer reading another’s recordstwo accounts
- A3Admin pages guarded only in the browsertwo accounts
money leak
7- P1Fake payment notifications your app believes
- P2The same payment counted twice
- P3Prices your customer can change before paying
- P4People still using the app after cancelling
- A4Paid features a free account can calltwo accounts
- C2An AI endpoint strangers can run up your bill on
will break
6- C1No limit on password guesses at sign-in
- R1No database backups you could restore from
- F1Missing browser protections on every page
- F3Debug pages and error traces left public
- S4Your original source code, downloadable
- F2Any website allowed to call your API
Every check either reproduces the problem or reports suspected. A dollar figure only ever rides on a verified finding.
see all 24 →We don’t say “this looks risky”. We log in as someone else and show you their data.
Most scanners read your code and guess. Solacess creates two real sessions on your live app, replays account A’s requests as account B, and only reports what actually came back. If it cannot reproduce the leak, it says suspected — never verified.
Account B can read Account A’s invoices
GET /api/invoices/inv_8f2c session: account-A
→ 200 OK { "id": "inv_8f2c", "owner": "account-A" }GET /api/invoices/inv_8f2c session: account-B
→ 200 OK
{ "id": "inv_8f2c", "owner": "account-A",
"customer_email": "a•••@•••.com", "total": "•••" }redacted before it was stored · we never keep your customers’ data
Reproduced twice, four minutes apart. 1,240 invoices are reachable the same way.
table: invoices
Three steps, and you keep control of every one.
prove the app is yours
Add one DNS record, or drop a file on your domain. Until that passes, Solacess only looks at what your app already shows the public.
hand over two test logins
Two accounts you created for this, never a real customer’s. Stripe stays in test mode. Both are encrypted and deleted when the scan ends.
read what it proved
Findings in three buckets, each with the request that proved it and a fix prompt. Fix it, then run the scan again to confirm it is closed.
Pointing a scanner at your own app should not be the risk.
These four are enforced in the engine, not promised in a policy page.
nothing active until you prove ownership
Every test that touches your app refuses to run until the domain check passes — re-checked at scan time, not trusted from last week.
one throttled path, fully logged
Every request goes through a single rate-limited client and is written to an audit log. A scan never looks like an attack, and you can stop it mid-run.
test mode only, and it cleans up
Stripe checks refuse anything but a test key. Anything a check creates is tracked and removed when the scan ends, pass or fail.
your data does not stay with us
Proof is redacted before it is written. We keep no copy of your source and no customer records. Test sessions are deleted when the scan finishes.
Read one report before you decide anything.
A scan every week that needs no test logins, and an email when each one finishes.
Buying an app? A dated report before the money moves.
The ones people actually ask.
Will this break my live app?
It is throttled, logged and stoppable mid-run, and the only writes it makes are to test accounts you created. Stripe stays in test mode.
Do you store my code or my customers’ data?
No. Proof is redacted before it is written, and nothing of your source is kept.
Can I scan an app I don’t own?
No. Active tests refuse to run until you prove the domain is yours, and it is re-checked every scan.
What if it reports something that isn’t real?
A finding is only marked verified when the check reproduced it. Everything else is labelled suspected, and carries no dollar figure.
I’m not technical. Can I act on the report?
Each finding is written in plain words and ends with a prompt you paste into Cursor or Claude Code. Then run the scan again to check the fix.
Where does the dollar figure come from?
From what the check measured — the plan price it saw, the number of accounts affected. Every figure shows its basis, and it is an estimate, not a bill.
Does it work on apps not built with Lovable?
Yes. The checks care about Next.js, Supabase and Stripe, not which tool typed the code. Cursor and Claude Code apps are the main case.
Between a scanner that guesses and a pentest you cannot afford.
The middle column is what most vibe-code scanners do today: read the bundle and the config, match rules, report what the shape suggests.
| solacess | a typical scanner | a human pentest | |
|---|---|---|---|
| How it decides | Signs in as two customers and replays the request | Reads the bundle and config, matches rules | A person tries things by hand |
| What a finding shows you | The request and the response it came back with | A rule name and a severity | A written report, usually with steps |
| One customer reading another’s data | Yes — this is the main thing it does | Not without two live logins | Yes |
| Payment and subscription leaks | Yes, in Stripe test mode | Rarely | If you ask for it |
| What it costs | $79 a scan | free – $49/mo | thousands |
| How long you wait | minutes | minutes | weeks |
the middle column describes the category, not one named product · pentest prices vary widely · we are not a replacement for a pentest, and say so