Free self-check / Lovable + Supabase

5 security tests you can run right now.

No technical skills required. No code to read. Takes 10 minutes. If you built your app on Lovable + Supabase, run these before your next user signs up.

Why this matters right now. CVE-2025-48757 (CVSS 9.3 Critical) documented unauthenticated database access across 170+ production Lovable apps. The vulnerability: Row-Level Security disabled by default. These 5 checks find that issue and the four others most likely to cost you money or users. See the CVE on NIST.
01
The View Source check
Are your API keys visible to anyone who visits your site?

How to run it

  1. Open your deployed app in a browser (the live URL, not Lovable's preview)
  2. Right-click anywhere on the page and choose "View Page Source"
  3. A new tab opens with raw code. Press Cmd+F (Mac) or Ctrl+F (Windows)
  4. Search for each of these strings one at a time: sk_live, sk_test, sk-proj, service_role, OPENAI, ANTHROPIC
Pass None of those searches return actual key values. (Finding the word "key" in a variable name is fine. Finding a long string like sk_live_abc123... is not.)
Fail Any search returns what looks like an actual API key. That key is now public. Anyone visiting your site has it. Rotate it immediately before fixing the underlying issue.
02
The Supabase RLS check
Can strangers read your users' private data?

How to run it

  1. Open your Supabase dashboard at supabase.com/dashboard
  2. Select your project
  3. Click "Database" in the left sidebar, then "Tables"
  4. Look at the column labeled "RLS" for every table in the public schema

What you are looking for

Every table that stores user data (profiles, messages, orders, subscriptions, anything with private information) needs RLS enabled with at least one policy.

Pass Every table shows "Enabled" with a shield icon. Tables that only store public data (like a product catalog everyone can see) can be "Disabled" intentionally.
Fail Any table with private user data shows "Disabled." This is CVE-2025-48757. Anyone with your Supabase anon key (it's in your JS bundle by design) can read that entire table. See the full fix guide.
03
The anonymous access check
Can someone see your app's data without logging in?

How to run it

  1. Open an incognito or private browser window (this ensures you are not logged in)
  2. Visit your app's URL
  3. Try to navigate to any page or section that should require a login, such as a dashboard, profile page, or data view
  4. Try adding /dashboard, /admin, /profile, or similar paths to your URL if there is no obvious private section
Pass You get redirected to the login page, or you see a blank/error state with no actual user data visible.
Fail You can see any private data (other users' content, admin panels, user lists) without logging in. Your authentication is not enforcing access correctly.
04
The Stripe webhook check
Can someone fake a payment and get your product for free?

How to run it

  1. Open your Stripe Dashboard and go to Developers → Webhooks
  2. Click on your webhook endpoint (the URL that receives payment events)
  3. Look for a "Signing secret" section. It should show a value starting with whsec_
  4. Now open your codebase (via Lovable or GitHub) and search for the word constructEvent
Pass Your webhook endpoint has a signing secret configured AND your code includes a call to constructEvent (or equivalent signature verification). Both must be true.
Fail No signing secret is set up, or constructEvent is missing from your webhook handler. Anyone who finds your webhook URL can POST fake payment events and trigger your fulfillment for free. See the full fix guide.
05
The rate limit check
Can one user run up a $2,000 OpenAI bill overnight?

How to run it (only applies if your app uses AI features)

  1. Open your app and find the AI feature (chat, generate, summarize, or similar)
  2. Send the same message 10 times in a row as fast as you can
  3. Watch whether the app slows down, blocks you, or keeps responding normally
  4. Alternatively: open your OpenAI or Anthropic dashboard and check whether there is a monthly spend cap or usage alert configured
Pass After a few rapid requests the app starts returning errors or slowing down. Or you have a spend cap set in your provider dashboard.
Fail The app responds to all 10 requests without any throttling. One user with a script could send thousands of requests overnight. Stories of $2,000+ bills from a single bad actor are common. See the full fix guide.

What your results actually mean

You passed all 5.

Good. These are the easy checks, the ones that can be verified without code access. They catch the most obvious failure modes. They do not catch the hard ones: multi-table RLS edge cases, business logic exploits, payment flow vulnerabilities, input validation gaps, or the patterns Lovable's built-in scanner flags but does not evaluate. If you have paying users or B2B clients, a deeper audit is worth doing.

You failed 1 or 2.

Fix the ones you can from the guides above. If you want someone to verify the fix worked and check the rest of the surface area, the $99 Spot Check covers one area in depth with a 5-10 minute Loom showing exactly what was found.

You failed 3 or more.

This is the most common result for Lovable apps that have been live for under 6 months. None of these failures are your fault. Lovable builds apps that work. The security layer is left to you, and most non-technical founders do not know it exists. The full audit finds every issue across all 14 patterns and the cleanup fixes them. Fixed price, done in 14 days.

Start a $99 spot check See all tiers Full 14-item checklist