What went wrong in real apps
In 2025 a researcher scanned 1,645 apps from Lovable's showcase and found 170 projects whose database rules let anyone read data such as names, payment details and API keys (CVE-2025-48757, disputed by Lovable). The cause was missing or weak row-level security, a database setting rather than a bug in the code. Lovable has since added a security scan, and says it can't guarantee your app will be 100% secure. Studies of vibe-coded apps in general keep finding the same few problems; see is my vibe-coded app secure?
Which keys are fine in front-end code?
| Key | In the browser code? | Why |
|---|---|---|
| Supabase anon / publishable key | OK | Public by design, but only safe with correct RLS on every table. |
| Supabase service_role / secret key | Never | Skips all database rules. Anyone with it can read and change everything. |
| Stripe secret key (sk_live_…) | Never | Lets anyone take payments and issue refunds. |
| OpenAI, Anthropic or other AI keys | Never | Anyone can run up your bill. Call the AI from a server function instead. |
| Stripe publishable key (pk_…) | OK | Made to be public. |
Check your app's code
- Get the code onto your computer. In Lovable, Bolt, v0 or Replit, connect the project to GitHub, then download or clone the repository.
- Install the free checker:
pip install appledger - Run it on the folder:
python -m appledger path/to/your-app - Fix and re-check. Open
.appledger/fix-prompt.md, paste it into your builder's chat, then run the check again.
The check reads the code itself: secrets written into files, packages with known security holes, and dangerous code patterns. Your files are sent over HTTPS, scanned with Trivy and Opengrep, and deleted right after.
Your code contains a live Stripe payment key
Anyone who can see this file can take payments, issue refunds and read your customers' payment details.
Example from a sample app. If a key shows up here, create a new one at the provider and revoke the old one: it's already leaked.
Check your database rules in Supabase
- Open your project in Supabase and go to Advisors → Security Advisor.
- Fix every warning about tables without row-level security.
- For each table, ask: “Should a logged-out visitor see this? Should one user see another user's rows?” If not, the policy must say so.
Isn't the builder's own scan enough?
It's a good start, and you should use it. A second, independent check helps because it works the same way for every builder, shows every finding in plain English, and gives you a fix request you can paste back.
RLS settings and policies, storage bucket rules or other Supabase and Firebase dashboard settings; whether your login and permission logic is right; secrets stored only in the builder's settings; the live, deployed site; and code you haven't exported.
Questions
Is the Supabase anon key safe in front-end code?
Yes, it is meant to be public. It is only safe if row-level security (RLS) is switched on and correct for every table. The service_role key must never be in front-end code.
Isn't Lovable's built-in scan enough?
It's a good start. An independent check adds a second opinion that works the same for every builder, shows all findings in plain English, and gives you a fix request to paste back.
Can AppLedger check my Supabase RLS rules?
No. RLS lives in your database, not in your code. Use Supabase's Security Advisor for that.
How do I get my app's code?
Connect your project to GitHub in the builder, then clone or download the repository to your computer and run the check on that folder.