Supabase Security Checklist for AI-Built Apps

Supabase is one of the best tools for shipping fast. It is also one of the fastest ways to ship broken authorization if the generated defaults go unreviewed.

01. Start with the service role question

If the service role ever reaches the browser, your security model is gone.

That still happens in AI-assisted scaffolds because models often optimize for “make the query work now” instead of “preserve least privilege.”

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY!,
);

That pattern is never acceptable in client code, no matter how polished the feature looks.

02. Audit your RLS policies as behavior, not syntax

The most deceptive Supabase bugs are policies that read secure and still expose the wrong rows.

Example edge case:

create policy "Users can read team docs"
on team_documents
for select
using (team_id in (
  select team_id from memberships
));

That compiles. It also ignores auth.uid(), which means it does not actually scope access to the current user.

03. Buckets and signed URLs deserve their own review

AI agents frequently scaffold file upload flows without clearly separating:

1. 01. public assets
2. 02. private user files
3. 03. expiring access
4. 04. admin-only exports

Review every storage bucket explicitly. If a bucket contains contracts, invoices, generated reports, or internal screenshots, assume it should not be public.

04. [Component: DarkWireframeKey]

The DarkWireframeKey diagram here should show four Supabase lanes: browser, auth token, Postgres tables, and storage. The visual needs a distinct red crossing from the browser to the service-role or public bucket lane, because that is the exact failure pattern this checklist is meant to highlight.

05. Review RPCs, edge functions, and joins

Supabase makes it easy to hide complex logic behind RPCs and helper functions. That is convenient, but it also makes authorization drift easier to miss.

Look for:

1. 01. RPCs callable by more roles than intended
2. 02. joins that expose more columns than the client needs
3. 03. edge functions that trust client-provided userId
4. 04. policies that rely on stale membership assumptions

06. Validate JWT-dependent assumptions

JWT payloads are useful for identity and context, but AI-generated code often over-trusts custom claims without validating how they are issued or refreshed.

Ask:

1. 01. where do role claims come from?
2. 02. who can change them?
3. 03. what happens when membership changes mid-session?

07. The minimum Supabase review before launch

1. 01. no service role in client code
2. 02. RLS enabled on sensitive tables
3. 03. every policy tied to the active user
4. 04. private storage buckets verified
5. 05. RPCs reviewed for execution scope
6. 06. auth claims explained in plain English

If you cannot explain those six points clearly, the app is not production-ready yet.