Security Checklist for Supabase Apps Built with AI

Supabase is the default backend for most AI-generated apps. Its combination of PostgreSQL, auth, storage, and realtime makes it a one-stop shop. But AI tools consistently misconfigure the security boundaries between the anon key (safe for clients) and the service role key (must stay on the server).

12-point security checklist

1. 1.

   Service role key is NOT in client code

   critical

   The SUPABASE_SERVICE_ROLE_KEY must never appear in client-side code or NEXT_PUBLIC_ variables. This key bypasses all RLS policies. Search your entire codebase for the service role key value — it should only exist in server-side environment variables.

2. 2.

   Row Level Security enabled on all tables

   critical

   Every table in your Supabase database must have RLS enabled. Without RLS, any authenticated user can read and modify any row. Check the Supabase dashboard → Table Editor → each table should show "RLS enabled". AI tools create tables but almost never create RLS policies.

3. 3.

   RLS policies are correct and restrictive

   critical

   Having RLS enabled is not enough — the policies must correctly restrict access. Common AI mistakes: policies that use auth.uid() but allow users to read all rows, INSERT policies without a user ID check, UPDATE/DELETE policies that are too permissive. Every policy should be tested with different user contexts.

4. 4.

   Storage buckets have proper policies

   high

   Supabase storage buckets default to private, but AI tools often make them public for convenience. Check each bucket's policies: who can upload, who can read, what file types are allowed, and what size limits exist. A public bucket means anyone can upload or download any file.

5. 5.

   Auth email templates are customized

   medium

   Default Supabase auth emails contain generic text and Supabase branding. For production, customize confirmation, password reset, and magic link email templates. Also verify redirect URLs point to your domain, not localhost.

6. 6.

   Auth redirect URLs whitelisted

   high

   In Supabase auth settings, only your production domain(s) should be in the redirect URL whitelist. AI setups often include localhost:3000 in production, allowing attackers to redirect auth flows to their own servers.

7. 7.

   Database functions don't use SECURITY DEFINER carelessly

   high

   Supabase/PostgreSQL functions with SECURITY DEFINER run with the permissions of the function creator (usually superuser), bypassing RLS. AI-generated database functions often use this flag for convenience, creating privilege escalation paths.

8. 8.

   No direct database URL in client code

   critical

   The direct database connection string (postgresql://...) must never appear in client code. AI tools sometimes use it for direct database queries in places where they should use the Supabase client with the anon key.

9. 9.

   Email confirmation required for signups

   medium

   Verify that email confirmation is enabled in your Supabase auth settings. Without it, anyone can create accounts with fake emails, making abuse and spam trivial.

10. 10.

    Realtime subscriptions respect RLS

    high

    If you use Supabase Realtime, verify that the subscriptions respect RLS policies. AI tools sometimes enable realtime on tables without proper RLS, allowing any connected client to receive all changes from all users.

11. 11.

    Edge Functions validate input

    medium

    Supabase Edge Functions receive raw HTTP requests. AI-generated functions often trust input without validation. Every Edge Function should validate request body, query parameters, and headers before processing.

12. 12.

    No unused or test API keys in production

    medium

    Check that your production environment only contains production Supabase keys. AI development often creates test projects — make sure test keys didn't accidentally end up in your production .env file.