RLS Radar
Free · read-only · nothing stored

Is your vibe-coded app leaking keys or data?

Built with Lovable, Bolt, Cursor, Claude or v0? Paste your URL. RLS Radar checks your public frontend for leaked secret API keys, exposed .env / .git files and missing security headers. If your app runs on Supabase or Firebase, it also tests, read-only, whether your database answers to strangers.

  • Reads only public HTML/JS
  • Status codes and counts, never your data
  • No writes, no exploits
  • Results not stored

We fetch your page and same-origin scripts plus a few small same-origin GETs (/.env, /.git/config, a source map). Only if we find a Supabase or Firebase config do we send read-only checks to that backend. Full methodology.

Example result
1 critical1 high1 ok
Criticalservice_role key found in frontend bundle
This key bypasses Row Level Security. Rotate it now and move it to a server-only environment.
HighTable profiles answers to the anon key
A zero-row count request succeeded. Enable RLS and add an ownership policy.
OKPublishable key exposed (expected)
Safe by design when RLS is on.

How it works

Three steps from URL to fix.

  1. Paste your URL

    Confirm you own the app. Private and internal addresses are refused, including after redirects and DNS resolution.

  2. We look like a visitor

    We read the HTML and same-origin JavaScript a browser would get, look for secret keys and Supabase or Firebase configs, and classify each key. Then a few small read-only requests: dotfiles, headers, source maps and, if found, your backend.

  3. Get findings + a fix prompt

    Severity-ranked findings, read-only table signals, and a copy-paste prompt for Cursor or Claude to fix what we found (RLS, Firebase rules, keys, headers).

What we check — and what we never do

Open methodology. Every claim below follows the vendor's own documentation. Works on any public site; Supabase and Firebase get extra read-only backend checks.

Leaked Supabase secret keys

service_role or sb_secret_ keys in the browser bypass RLS entirely. Supabase says to rotate them (API keys docs).

Public keys, correctly classified

The anon / sb_publishable_ key is meant to be public. We flag it as expected, not as a leak.

Read-only RLS signals

Table names from the API schema plus limit=0 count requests. A table that answers the anon key probably has RLS off or a USING (true) policy (RLS docs).

Secret API keys in any frontend

Well-known, high-confidence key prefixes only: OpenAI, Anthropic, Stripe live secret/restricted (sk_live_, rk_live_), GitHub, AWS access key IDs, Slack. Publishable keys like Stripe pk_ are never flagged. Keys are masked (first 6 + last 4) and never stored. Google AIza keys are Info: often public, but should be restricted.

Exposed .env and .git

Small, range-limited GETs for /.env, /.env.local and /.git/config on your own origin. Flagged only if the response really looks like that file, so single-page-app fallbacks that return index.html do not count. We never show or keep the contents.

Firebase Security Rules

Your Firebase web config is public by design (Firebase docs); your rules are what protect data. We check, read-only, whether the Realtime Database root (shallow=true, key count only), Firestore collections named in your code (pageSize=1) and Storage listing (maxResults=1) answer without sign-in.

Headers and source maps

Missing CSP, HSTS, X-Frame-Options / frame-ancestors and X-Content-Type-Options are reported as Low: defense in depth, not a leak. Public production source maps are Info.

Never

Only GET/HEAD requests. No row, document or file contents returned, no writes, no exploit payloads, no brute force, no storage of scan inputs or results. Private and cloud-metadata addresses are refused on every request and redirect. Scans require an ownership confirmation.

Guides

Short, sourced answers to the questions builders ask most.

Storage buckets: public vs privatePer-user folder policies, signed URLs. RLS for multi-tenant appsauth.uid() + org membership policies. Supabase Oct 30 Data API changeNew tables need GRANTs. RLS still decides rows. Supabase RLS checklistEnable RLS, kill USING(true), lock storage. Supabase anon key exposed: what it meansWhen it is fine, and when it is not. How to check if RLS is enabledSQL queries and dashboard steps. Leaked service_role / secret keyRotation steps, in order. Before you ship an AI / vibe-coded app15-minute go-live hardening.

FAQ

Does RLS Radar work if my app doesn't use Supabase?

Yes. Every scan runs the universal checks on any public site: leaked secret API keys in your page and same-origin JavaScript, exposed .env and .git/config files, security headers and public source maps. Supabase and Firebase apps also get read-only backend checks. If neither is detected, the report says so and lists the supported backends.

Is it safe that my Supabase anon or publishable key is visible in the browser?

Yes, by design. Supabase documents the publishable key (and the legacy anon key) as safe to expose in web pages and apps. It maps to the anon Postgres role, so it can only reach what your grants and Row Level Security (RLS) policies allow. The danger is tables without RLS, or policies that are too open.

Is my Firebase apiKey in the frontend a leak?

No. Firebase says API keys for Firebase services only identify your project and app, and are public by design. Your Realtime Database, Firestore and Storage data is protected by Firebase Security Rules and App Check, not by hiding the key. Do restrict the key to Firebase APIs, and never allow the Gemini (Generative Language) API on it.

What if my service_role or sb_secret_ key is in my frontend?

Treat it as a leak. Secret and service_role keys bypass Row Level Security entirely. Supabase recommends fixing the root cause, creating a new secret key, replacing it everywhere, then deleting or deactivating the leaked key.

Does RLS Radar download my data?

No. It reads your public HTML and same-origin JavaScript and sends a few small read-only requests. For Supabase it sends zero-row count requests (limit=0) and reads table names from the API schema. For Firebase it keeps only status codes, readable or blocked, and the number of top-level Realtime Database keys. For .env and .git files it only decides whether the file is exposed. It never returns row, document or file contents, never writes, and stores no scan results. It only keeps anonymous totals (how many scans ran and the worst severity found), never the URL, your IP, keys or findings.

Who is allowed to run a scan?

Only the owner of the app or someone with explicit permission to security-test it. The scanner refuses to run unless you tick the permission checkbox.

Does a clean scan mean my app is secure?

No. RLS Radar only sees what is reachable from the public frontend. Lazy-loaded bundles, policies for signed-in users, Firestore collections not named in your code, views, functions and storage object policies need your own review and tests (Supabase recommends pgTAP tests via supabase test db; Firebase recommends testing rules with the Emulator Suite).

How much does RLS Radar cost?

The scan is free.

Supabase security notes

Occasional notes on RLS mistakes we see in AI-built apps. We store only your email address, with our email provider (Resend).

By subscribing you agree to receive occasional emails from RLS Radar. No emails are being sent yet. Each email will include an unsubscribe link, and you can unsubscribe or ask for deletion anytime at rlsradar@mail.grokbot.com. See Privacy.

Support / donate: a way to support RLS Radar is coming soon.