Supabase misconfiguration scanner: prelaunch checks

A supabase misconfiguration scanner should answer one question: can a public user, anonymous browser session, or leaked client key reach data or controls that should stay private? For launch teams, the answer depends on RLS, storage, auth, exposed variables, and API boundaries. Use the scan to find unsafe defaults before real users and crawlers hit production.

What the scan should catch?

A good Supabase config scan is not just a port scan or dependency check. It should inspect how the hosted app behaves from the outside, then connect those findings to common Supabase failure patterns.

The highest-risk findings usually look simple:

RLS disabled on tables that contain user, billing, admin, or tenant data.
anonymous overreach where anon users can read or write more than intended.
public storage buckets containing invoices, avatars, exports, resumes, or uploads.
service role leakage through frontend bundles, logs, source maps, or public config.
unsafe auth redirects that allow account takeover paths or token capture.

These issues often appear in AI-built apps because generated code optimizes for working features first. The app signs in, writes rows, uploads files, and calls APIs. Security boundaries are added later, or assumed to exist because Supabase has strong primitives.

The dangerous part is that Supabase can be secure and still be configured unsafely. A table can have policies, but those policies may allow every authenticated user to read every tenant. A bucket can be private, while a signed URL endpoint gives files to anyone who guesses an ID.

For RLS-heavy projects, pair the scan with a focused Supabase RLS checker. Policy review needs context: who owns each row, which roles exist, and whether admin functions bypass normal user rules.

How to verify risky settings?

Start with the database boundary. Every production table that stores customer data should have row-level security enabled, and policies should map to real product rules. RLS must be explicit because missing or broad policies are not harmless during launch traffic.

A quick SQL review can expose obvious misconfigurations before a deeper scan:

sql

-- Run in a safe read-only review session
select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity asc, tablename;

select id, name, public
from storage.buckets
order by public desc, name;

This does not prove the app is safe. It only highlights where to investigate first. A table with RLS enabled can still have a permissive policy such as using (true). A private bucket can still be exposed through an API route.

Next, verify storage behavior from the public app. Upload flows are common weak points in generated applications. A user uploads a file, the UI previews it, and the backend stores a path. If paths are predictable, one tenant may fetch another tenant's file through a weak download endpoint.

Treat public means public as a hard rule. If a bucket contains anything a user would not post on a public profile, it should not be public. Prefer private buckets with short-lived signed URLs and server-side authorization checks.

Then check secrets. Supabase anon keys belong in the browser, but service role keys do not. Look through built JavaScript, source maps, public .env files, deployment logs, and client-readable runtime config. Use a public .env exposure check when you deploy from templates or AI-generated project scaffolds.

Also review auth settings. Redirect URLs should be restricted to trusted domains. Email confirmation, magic links, password reset links, and OAuth callbacks should not accept arbitrary destinations. Weak redirect handling can turn a normal login flow into token theft.

A broader Supabase security scan helps connect these checks across database, storage, frontend exposure, and public routes. The goal is not to flag every theoretical issue. The goal is to find launch-blocking exposure paths.

Prelaunch checklist

Use this checklist after the app works, but before announcing it. It is designed for small teams shipping quickly, where one founder or developer owns the release.

Map sensitive tables: list user profiles, subscriptions, messages, files, orders, API tokens, and admin tables.
Confirm RLS status: make sure every sensitive public schema table has row-level security enabled.
Read every policy: reject policies that allow broad select, insert, update, or delete without tenant checks.
Test as anonymous: open the app in a clean browser and inspect reachable data before login.
Test as user A: try to access user B records by changing IDs, slugs, filters, or API parameters.
Review storage buckets: keep sensitive uploads private and authorize downloads through server-side logic.
Search built assets: scan bundles, source maps, and public config for service keys or backend secrets.
Lock auth redirects: allow only production domains and required preview domains.
Remove debug endpoints: disable seed routes, admin helpers, test APIs, and SQL execution tools.
Rescan production: validate the deployed app, not only the local repository.

The production step matters because deployments change behavior. Environment variables may differ, preview URLs may remain active, and build systems may expose files that were never visible locally. A local review is useful, but public exposure happens at the deployed edge.

For secret-heavy launches, add a dedicated frontend check such as detect exposed API keys. Supabase projects often sit beside payment, email, analytics, and AI provider keys, and one exposed key can widen the incident.

If the scan finds a problem, do not only patch the visible symptom. Rotate exposed secrets, invalidate sessions if needed, inspect logs for suspicious access, and add a regression check. Fix, then rescan should be the release habit.

Launch with fewer surprises

A scanner cannot replace sound authorization design, but it can catch the mistakes that most often turn a fast launch into a data exposure. Use a security scan for the public surface, then add a deep scan when you need broader validation across routes, secrets, and configuration.

The best outcome is boring: no public buckets with private files, no service role key in JavaScript, no cross-tenant reads, and no permissive policies hidden behind a working UI. That is ship with evidence, not hope.

Faq

Does Supabase anon key exposure mean my app is hacked?

Not by itself. The anon key is designed for browser use. The risk depends on your RLS policies, storage rules, and API routes. If policies are broad or missing, the anon key can become a path to unauthorized reads or writes.

Should i scan before or after enabling RLS?

Do both if possible. Scan before enabling RLS to find obvious exposure, then scan again after policies are implemented. The second pass is more valuable because it tests whether your intended access rules actually hold in the deployed application.

What is the most common Supabase launch mistake?

The most common serious mistake is assuming authentication equals authorization. A user being logged in does not mean they should access every row. Policies must enforce ownership, tenant boundaries, admin roles, and storage access at the data layer.

If you are close to launch, run AISHIPSAFE against the deployed app and review the findings before inviting real users.