Security check for your app

Your app works, so it’s done? No: AI builders make apps that work, not necessarily apps that are locked down. Do this check before you let real users in.

After this lesson you have: put your app through ten checks, with free tools, and you know what to do if something leaks anyway.

How it went wrong for others

What	When	Cause	Result
Lovable (CVE-2025-48757)	reported Mar 2025	RLS missing or wrong in generated apps	170 of 1,645 scanned apps leaked emails, payment details and API keys. In one app the researchers set the payment status to “paid” themselves.
Moltbook	Jan-Feb 2026	Supabase key in the frontend and no RLS	1.5 million API tokens and 35,000 email addresses readable and editable.
Base44	Jul 2025	The platform’s registration endpoints without checks	With just a publicly visible app ID you could create an account on “private” apps. Fixed within 24 hours.

The pattern: nobody broke in, the door was open. Two concepts you need to know:

• RLS (Row Level Security): rules in your database that determine which rows someone may see. Off = anyone with your project URL can read, change and delete everything.
• Publishable vs. secret key: the publishable key (sb_publishable_…, formerly anon) may go in the browser. The secret key (sb_secret_…, formerly service_role) bypasses RLS and belongs only on a server.

The ten checks

#	Check	How to test it
1	RLS on every table	Supabase → Advisors → Security Advisor: zero errors. Then create two test accounts and see whether account B can see or change anything of account A’s.
2	No secret keys in the frontend	Open your live site → DevTools (F12) → search all files (Ctrl+Shift+F, Mac: Cmd+Option+F) for sb_secret, service_role, sk- and sk-ant-. One hit = a problem.
3	Login on every page, checked server-side	Log out and open every page and every /api/… URL directly in your browser. If you get in, only the button is checking, not the server.
4	Rate limiting	Ask your AI builder: “Where is there a limit on login, sign-up and every AI call?” Without a limit you pay someone else’s AI bill.
5	Input validation	Type <script>alert(1)</script> and a huge block of text into every form. Popup or crash? Then input isn’t being validated. Only on your own app.
6	Dependency audit	npm audit --omit=dev in your project folder, or turn on Dependabot alerts on GitHub.
7	Security headers	Scan your URL with securityheaders.com or the MDN HTTP Observatory. Aim for an A.
8	Backups	Check in your Supabase dashboard which backups your plan includes, and export your data yourself every month.
9	Logging and alerts	Know where your Supabase logs are and set a budget alert with every AI provider.
10	Privacy policy and GDPR	Privacy policy online, a data processing agreement with every service that receives personal data, EU region chosen where possible.

Free tools

Tool	What it finds	Where
Supabase Security Advisor	Tables without RLS (lint 0013_rls_disabled_in_public), policies that aren’t active	Supabase Studio → Advisors
npm audit	Known vulnerabilities in your packages	Terminal, in your project folder
Dependabot + secret scanning	Vulnerable packages and leaked keys in your repo	GitHub → your repo → Settings → Advanced Security
securityheaders.com / MDN HTTP Observatory	Missing security headers	In your browser
OWASP ZAP baseline	Passive scan: looks around, doesn’t attack	docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://jouw-app.nl

Only scan your own app. Scanning someone else’s site without permission can be a criminal offence.

Let the AI audit its own code

Open a new session (or a different model) and paste:

You are a security reviewer. Don't change anything yet.
1. List every database table. Per table: is RLS on, which policies exist for anon and authenticated, and can user A read or change user B's rows? Show the SQL.
2. Search all frontend code for keys, tokens and URLs containing passwords. Which belong on the server? Give file and line.
3. Make a table of all routes and API endpoints: which require login, and which check whether the user owns the data? Flag every route without an ownership check.
4. Write a test that uses two test accounts to try to read, change and delete each other's data. Report what succeeded.

This is no guarantee. The model that made the mistake often doesn’t see it: in a Lovable app with 18,697 leaked records (Feb 2026), the AI had written the login check exactly backwards. So ask for proof (a test that fails or passes), not reassurance.

Test with two accounts, not one

Almost every leak is “user A sees user B’s data”. With one account you’ll never notice, because you only see your own stuff. Two accounts, two browsers (or one incognito), and try each other’s pages and IDs in the URL.

Creating a new key doesn't revoke the old one

Did your Supabase key leak? Supabase says it itself: creating new keys does not revoke old ones. Explicitly delete or deactivate the leaked key. And remember why it’s so bad: “Policies never apply to a secret key”, so all your RLS is thin air.

Data breach? 72 hours

If personal data leaks, you report it “without undue delay and, where feasible, not later than 72 hours” after discovery to the Autoriteit Persoonsgegevens, the Dutch Data Protection Authority (Art. 33 GDPR). Only if the breach is unlikely to pose a risk do you not have to. With a high risk (ID photos, passwords) you also inform your users (Art. 34). Record every breach internally, even if you don’t report it.

Security

If it goes wrong anyway, do this in the first 15 minutes:

• Close the door: turn on RLS on the leaking table, or take the app offline.
• Rotate keys: deactivate every key that was in the frontend or in the leaked data (Supabase, OpenAI, Anthropic, Stripe) and set spend limits.
• Write down what, when and how many people. The 72-hour clock runs from the moment you know.
• Also check the rest of your AI use with the security scan.

Checklist

0/10

• RLS on for every table, tested with two accounts
• No secret key, service_role or sk- key to be found in the frontend
• Every page and API route refused when I'm logged out
• Rate limiting on login, sign-up and AI calls
• Forms tested with a script tag and long text
• npm audit or Dependabot without critical alerts
• Security headers scanned (goal: A)
• Backups checked and one export of my own made
• I know where my logs are, budget alert on
• Privacy policy and data processing agreements in place

Your progress is only stored in this browser.

Test yourself

1. 1Which Supabase key can be in your frontend?

   The secret key (sb_secret_ / service_role)The publishable key (sb_publishable_ / anon)Both, if RLS is on

2. 2Why do you test RLS with two accounts?

   Because Supabase requires itBecause with one account you can't see whether you can reach someone else's dataTo test the rate limiting

3. 3On Monday at 9:00 you discover that email addresses leaked. What's the latest you report it to the AP (the Dutch Data Protection Authority)?

   Within a monthWhere feasible, by Thursday 9:00 at the latestOnly if a user complains

Done with the Security basics learning path? Run the security scan again and see how much is green now.