ArgosX: independent security testing for AI-built apps

Security scan for Lovable apps

Lovable gets a Supabase-backed app working in minutes, and it gets the UI right. The security layer is yours to finish, and the same few gaps show up again and again: the public Supabase key ships inside your page, so any table without Row-Level Security is readable by anyone who opens the app. We scan the app you actually deployed, from the outside, the way a stranger would reach it.

Run the free scan on your Lovable app

Runs on your deployed URL in minutes. No signup, no card, and it never logs in: public surface only.

What Lovable apps typically get wrong

Row-Level Security off, or missing on some tables

Your anon key is in the page by design. Without RLS set per table, that key reads every row, no login needed. This is the number one leak in Lovable apps.

Private keys exposed to the browser

A service_role key or a private API key that ends up in client code is visible to every visitor, and it bypasses RLS entirely.

Sequential or guessable record IDs

Records numbered 1, 2, 3 make it trivial to enumerate other users' data once any read path is open. It turns one small leak into all of them.

What the scan checks on your live app

Supabase database exposure free scan

We use the anon key your live page already serves and check what it can actually read. If a table answers without a login, you see which one.

Secrets served to the browser free scan

We look for real private keys (service_role, private API keys) in the pages and bundles your app sends to visitors.

Security headers and config on the deploy free scan

CSP, HSTS, frame protection and the other one-line fixes fast deploys skip.

Cross-user access, signed in Pro, with your permission

On a Pro scan, with your permission and test accounts you provide, we sign in as two different users and check whether one can read the other's data, with the exact request and response as proof.

Being straight about scope: the free scan sees only what an anonymous visitor sees. Signed-in cross-user testing is a paid scan, needs your explicit permission and test accounts you provide, and takes tens of minutes because we actually drive the app. Plans on pricing.

Lovable has a built-in security review. Why scan again?

Use it. It is zero friction and it runs right where you build. What an independent scan adds: it is not the vendor grading its own output, it tests the app you deployed rather than the code as written, and on a Pro scan it does the one thing a code review cannot: sign in as two real users and prove whether your data separation holds at runtime.

Common questions

Is it safe to run this on my Lovable app?

The free scan only touches your public surface: the pages and endpoints any anonymous visitor can already reach. It does not log in, create accounts or write data. Signed-in testing only happens on a paid scan, with your explicit permission and test accounts you provide.

What does the free scan not cover?

Anything behind a login. A free scan cannot tell you whether user A can read user B's data, because that requires signing in as both. That cross-user check is what the Pro scan exists for.

Run the free scan

Prefer the checklist first? See the Lovable pre-launch checklist.

Platform behavior described as of September 2026. Platforms change their defaults; the scan tests what your app actually does today.