What the live app check looks for
- Stack and client library fingerprint with a curated free CVE pack (including CVE-2025-29927), Firebase path probes, OpenAPI GET expansion, Appwrite/PocketBase/Hasura/Convex, Fix now playbooks, Serious vs Hardening tips, and a README score badge
- Auth surface map, open-redirect probes, GraphQL introspection checks, and nested Supabase selects (read only)
- Risk score 0-100, peer comparison by stack (anonymous buckets only), TLS expiry and HTTPS redirect notes
- Email spoofing protection for your own domain: SPF and DMARC records, mail provider, and DKIM for Resend, Google Workspace or Microsoft 365, with the exact DNS records to add (read-only DNS lookups, no email sent)
- Export Markdown report, copy a shareable summary, and one-click copy a README badge snippet; scan again anytime to see what improved
What the code check looks for
- OpenAI, Anthropic, Google (Gemini, Maps), Groq, xAI, Replicate, Hugging Face tokens
- Stripe or Clerk secret and publishable keys, Stripe restricted keys, and Stripe or Clerk webhook signing secrets
- Supabase service role keys (legacy JWT with role service_role) and new sb_secret_ keys
- AWS access key IDs and secret keys, GitHub and GitLab tokens, Slack tokens and webhooks
- Twilio, SendGrid, Resend, Discord webhooks, private key blocks, and database URLs with a password
- Generic secret assignments, such as SECRET=, TOKEN=, or PASSWORD= with a long value
Publishable values like a Stripe pk_ key or a Firebase web config are shown as public, so you can tell them apart from real secrets. A Supabase anon or publishable key is never counted as a leak and never lowers your grade. It is meant to be public. The live app scan uses it, read only, to check what it can access, and names each table it can read when Row Level Security is off or too broad. A service role or sb_secret_ key is always critical. See anon key vs service role key.
If it finds a live secret
Rotate the key at the provider first, then remove it from code and git history. Deleting the line is not enough once it was pushed or deployed. Follow the first hour after an API key leaks and check your GitHub history.
A token in a committed .cursor/mcp.json or .mcp.json counts too. The MCP server security guide shows how to reference environment variables instead, and how to scope those tokens.
Code check limits
The repo scan reads the current branch only, not old commits, and stops at 150 files. Pattern matching misses keys with no fixed format and can flag test values. A clean result is not proof that a project is safe: a missing auth check, like an admin page guarded only in the browser, never shows up in a key scan (client-side auth is not security). For private repos and full history, run Gitleaks or TruffleHog on your own machine or in CI.
Ownership
When you add an app to Pro, you prove you control it with a small file at /.well-known/vibelocked-verify.txt or a DNS TXT record on _vibelocked-verify. Verified apps get deeper read-only checks. We still never write data or create users.
The data behind it
We ran these same read-only checks against 2,511 live vibe-coded apps on nine platforms. About one in five Supabase apps left a database table open to anyone. Read the study. If your Supabase dashboard already shows "RLS Disabled in Public" or similar warnings, Supabase Security Advisor warnings explained has the SQL fix for each one.
Live app check limits
This is an outside read of a public URL. A clean result is not a guarantee. Cap: about 20 same-origin scripts, about 1.5 MB each, short timeouts, capped probe counts.
It never signs in or creates users, so Supabase Auth flow gaps stay out of view. Check those yourself: password reset security, signup user enumeration, email change security, and sessions that keep working after sign out.
Related: exposed .env, .git, and source maps, anon vs service role, CORS misconfiguration, CSP for vibe-coded apps.
Questions
Is LeakCheck a Supabase RLS checker?
Partly. The live app scan uses your public anon key, read only, and names each table it can read when Row Level Security is off or too broad. It never signs in, writes data or creates users, so it cannot read your policies or test what one signed in user can see of another. A Supabase anon or publishable key never lowers your grade; a service role or sb_secret_ key is always critical.
Can I scan a Lovable, Bolt or Cursor app?
Yes. Paste any public URL, on a lovable.app address or your own domain. LeakCheck recognizes Lovable, Bolt, v0, Supabase, Firebase and Next.js from the page and checks it the way a stranger would.
How does the exposed API key check work?
The live scan reads your HTML and up to about 20 same-origin scripts for secret keys such as OpenAI, Anthropic, Stripe, AWS, GitHub and Supabase service role, and checks for exposed .env, .git and source map files. The code check reads a public GitHub repo, current branch only, up to 150 files. Values are masked.
Will LeakCheck ask for my code or secrets?
No. It only reads what is already public: your live URL or a public repo. It never asks you to paste a key, and it never writes data or creates users.
What is free and what does Pro add?
One preview scan needs no account: a score and every finding by title. Sign in free for more scans and the full top fixes. LeakCheck Pro (US$15 a month, CA$20 in Canada) keeps watching up to 5 apps on a schedule, keeps a full report, and emails you if something gets worse.