Is your app leaking data? Check it in 10 minutes.

Before you start

Use two test accounts you created yourself, never real customers' accounts, and only test an app you own or have permission to test. Keep your Supabase or Firebase dashboard open in another tab.

Built with Lovable? Run its security scan too. Lovable says it scans apps for security issues before you publish, with Supabase's Security Advisor built in, and also says it can't guarantee an app is 100% secure. The checks below look at your app from the outside, the way a stranger would.

1. Run a free outside scan (1 minute)

Paste your app's address into our free App Leak Scan. In about five seconds it grades your HTTPS, security headers and publicly downloadable source maps, and flags obvious keys exposed in the page. There's no signup, and it reads only what your app already sends to every browser.

2. Check your database rules (2 minutes)

Supabase: open the Security Advisor (under Advisors in your project dashboard) and fix anything marked as an error first. The most serious is "RLS disabled in public", which Supabase describes this way: "Anyone with your project URL can read, edit, and delete all data in this table." Then read each table's policies. A policy written as using (true) lets everyone it applies to read every row: right for public data, wrong for anything private. Private rows need an owner check such as (select auth.uid()) = user_id.

Firebase: open your Firestore or Storage rules. Firebase's own docs flag two patterns: allow read, write: if true;, which lets anyone overwrite your entire database, and a bare if request.auth != null;, which gives any signed-in user access to all of your data. Private data should check ownership, for example request.auth.uid == userId.

3. Search your front end for secret keys (2 minutes)

Open your app, open your browser's developer tools (F12), and press Ctrl+Shift+F (Cmd+Option+F on a Mac) to search every file the page loaded. Search for each of these:

• sb_secret_: a Supabase secret key. It must never be in the browser.
• eyJ: the start of every older-style Supabase key, and of other tokens. Compare any match with the keys under Settings, API Keys in your Supabase dashboard. The anon key is meant to be public; the service_role key is not.
• sk_live: a Stripe secret key. Keys starting pk_live are publishable and fine.
• sk-proj- and sk-ant-: OpenAI and Anthropic API keys, which belong only on your server.

Two things are fine to find: Supabase's publishable or anon key, because row-level security decides what it can reach, and Firebase config keys, which Firebase says don't need to be secret (just make sure that Google key isn't also allowed to call the Gemini API). And anything in a variable starting NEXT_PUBLIC_ or VITE_ is shipped to every visitor, so no secrets there.

Found a secret key? Supabase's advice: fix how it leaked first, then create a new key, swap it in everywhere, and only then delete the old one. Supabase blocks secret keys sent from browsers, but as its docs point out, an attacker can still use a leaked key from other tools.

4. The two-account test (3 minutes)

This is the check that matters most. OWASP ranks broken object level authorization, one user reaching another user's records by changing an id, as the number one API security risk. To test it:

• Sign in as test user A and open one of A's records: an order, an invoice, a profile or a document. Copy the address from the address bar.
• Open a private window, sign in as test user B, and paste that address.
• If B can see A's record, other signed-in users can probably read it too. Stop and fix it before you take more signups or payments.
• Paste the same address into a private window without signing in. It should ask you to sign in, not show the data.

Comfortable in developer tools? While signed in as B, find the request in the Network tab that loads one of B's records, right-click it and choose Copy as fetch. Paste it into the Console, change the id to one of A's, and run it. If A's data comes back, the hole is in your API, not just the page.

5. Check for public source maps (1 minute)

Source maps turn your compiled code back into your original, readable files. In developer tools, open the Sources panel: if you can browse your original folders and files (things like src/components) with readable code, your source maps are public. You can also add .map to the end of one of your JavaScript file addresses and see whether it loads.

Next.js and Vite both leave browser source maps off in production builds by default, so if yours are public, someone turned them on. Turn them off, or keep the .map files for your error tracker without deploying them. Readable code makes it much easier for a stranger to map your endpoints and logic.

6. Look at your security headers (1 minute)

In developer tools, open the Network tab, reload the page and click the first request (the page itself). Under Response Headers, look for:

• Strict-Transport-Security: tells browsers to use HTTPS only.
• Content-Security-Policy: limits which scripts can run, which blunts many injection attacks.
• X-Content-Type-Options: nosniff: stops browsers guessing file types.
• Frame protection, frame-ancestors in the Content-Security-Policy or X-Frame-Options, so other sites can't load yours in a hidden frame.

A missing header isn't a leak by itself, but each one is cheap protection, and most hosts let you add them in a single config file.

What your results mean

• Fix today: an RLS error in the Security Advisor, a failed two-account test, or a secret key in the browser. Each one can expose customer data.
• Fix this week: public source maps and missing security headers.
• All clear? A good start. These checks don't cover payments, rate limits or authorization on every server route. Our guide to five security holes to check before launch covers those.

Want a second pair of eyes?

The Launch-Safe Kit ($49) has all 30 checks from our paid audits, with copy-paste fixes, tested Supabase RLS recipes and security headers ready to paste. If you'd rather we look, the $299 Quick Scan reviews the five highest-risk areas from your code in 2–3 days, and the $499 Leak Check tests your live app from the outside with no code access.

Quick answers

How do I check if my Supabase app is leaking data? Open the Security Advisor in your Supabase dashboard and fix any "RLS disabled" errors, check that private tables have owner-only policies, search your front-end code for secret keys, and try to open one test user's records while signed in as another. Our free App Leak Scan checks HTTPS, security headers and source maps in about five seconds.

Is the Supabase anon or publishable key safe to expose? Yes, by design. Supabase says publishable keys are safe to put in web pages and apps, and row-level security decides what they can reach, so enable it on every table. Secret and service_role keys must never be in the browser.

Are Firebase API keys secret? Not the ones restricted to Firebase services: Firebase says they're fine to include in code, and your security rules protect the data. Do restrict the key, and never let a public key call the Gemini Developer API.

What is broken object level authorization? It's when an app returns a record by its id without checking that it belongs to the person asking, so changing a number shows someone else's data. It's also called IDOR, and OWASP ranks it the number one API security risk.

Does Lovable's security scan catch everything? No scan does. Lovable scans your app before you publish, with Supabase's Security Advisor built in, and says itself that it can't guarantee 100% security. Run the two-account test and a key search as well.

Sources

• Supabase: Row Level Security
• Supabase: API keys
• Supabase: database advisors (Security Advisor)
• Firebase: avoid insecure rules
• Firebase: API keys
• OWASP API Security Top 10 (2023): broken object level authorization
• Lovable: secure vibe coding (June 2025)
• Next.js: productionBrowserSourceMaps and Vite: build options
• MDN: Strict-Transport-Security
• Chrome DevTools: search all loaded files

Only test apps you own or are authorized to test. These checks are a quick screen, not a full security review.