Supabase RLS Checklist for Vibe-Coded Apps

A Supabase RLS checklist should start with what a user can do to the database, not what the app hides on screen. Supabase uses Postgres row level security to apply authorization rules inside the database. Its current documentation warns that a table in an exposed schema without RLS is readable and writable by roles that have the corresponding grants. A login page does not answer that database-access question. Source

This guide is for founders who built an app with AI coding tools and need a focused database check before inviting real users. It is narrower than a complete security audit. The platform behavior comes from Supabase's documentation; the review order and test matrix are our own synthesis. We have not inspected your project or tested a Codesprint client app for this article.

1. List the database objects your API exposes

Supabase's Data API security guide describes two access-control layers. Grants determine which roles can reach a table, view or function and perform an operation. RLS policies determine which rows a role can read or modify. The guide recommends using both controls for exposed objects and describes a dedicated API schema as an additional boundary around the public interface. Source

Our first review artifact is an inventory: exposed schemas, tables, views and callable functions, with the intended audience and permitted operations beside each. Include objects added by migrations and generated setup scripts, not only the tables you remember creating in the dashboard. Mark each object as public, user-owned, shared by a team or internal. If its audience is unclear, clarify the product rule before writing a policy.

Pay attention to defaults. Supabase says existing projects can automatically grant table privileges to anon, authenticated and service_role, while not every project does so. Adding policies does not revoke existing grants. Check your project's actual grants and default privileges rather than assuming all projects or all new tables have the same settings. Source

2. Confirm RLS is enabled on every exposed table

Supabase says RLS should be enabled on every table in an exposed schema. Once enabled, data is not accessible through the API with a publishable key until policies are created. That denial is a useful starting point, but it is not the finished access model. You still need the specific policies and grants that let intended users do their work. Source

Our recommendation is to keep this check in the migration review. An app can start with protected tables and add an unprotected one during a later feature build. Ask for evidence from the current database and the migration that creates each table. A screenshot taken before the last deployment is not proof that the deployed schema still has the same protection.

Do not fix an access error by turning RLS off. Supabase explains that a missing grant can produce a 42501 error before a policy runs. When an intended request fails, inspect the role, operation, grant and policy in that order. Otherwise a quick workaround can remove a control that was working correctly. Source

3. Write separate rules for reads and writes

A read policy is not a complete write policy. Supabase describes using as the expression that selects existing rows, while with check constrains a new or changed row. Inserts use with check. Updates can use both: one checks the row being targeted, and the other checks the resulting row so a user cannot transfer ownership to someone else. Source

For a simple user-owned table, Supabase's documented pattern compares auth.uid() with a user_id column and targets the authenticated role. The insert rule verifies the owner of the new row; the update rule verifies both the existing and resulting row. This is a pattern to adapt to your schema, not a universal rule for team membership, delegated access or administrator workflows. Source

Our checklist asks four separate product questions: who may read, insert, update and delete? Then it asks whether sensitive fields need different treatment. For example, a member might be allowed to edit a project title but not its billing account. Document those limits before accepting a generated policy called "users can access their data." A friendly policy name is not evidence of the SQL it enforces.

There are details worth testing. Supabase says an update needs a corresponding select policy to work as expected. It also notes that if an update policy omits with check, the using expression controls both visibility and the permitted new row. Do not diagnose behavior from policy names or assume every omission automatically means the same vulnerability. Read and test the actual expressions. Source

4. Test signed-out, signed-in and anonymous-user cases

Supabase distinguishes the database roles anon and authenticated. An anonymous user created through Supabase Auth is not the same as an unauthenticated request: that user uses the authenticated role. Policies should name their intended role with to, rather than relying on a vague idea that every visitor is either a full account holder or completely signed out. Supabase anonymous sign-ins

When a request has no authenticated user, including an expired or absent access token, auth.uid() returns null. Supabase points out that comparing null with a user ID does not evaluate to true. A signed-out request returning no rows can be correct behavior, but the app should handle it clearly instead of presenting an empty database as a successful signed-in session. Source

Our suggested tests use at least two separate users and a signed-out client. User A creates a record. User B attempts to read it, update it, delete it and insert another record with A's owner ID. Check the database state afterwards, not just the UI message. Then test the shared-access cases your product actually supports so a strict owner-only policy does not silently break collaboration.

5. Keep administrative keys out of the browser

Supabase's documentation says secret keys authorize administrative access through the service_role database role, which can bypass RLS. It says never to expose these keys to customers or use them in a browser. It also identifies the older JWT-based service_role key as a legacy alternative. A protected table is not a reason to ship a privileged key in client code. Source

There is an important qualification: Supabase says a request carrying a user access token runs under that user's RLS policies even when the client library was initialized with a secret key. Do not assume every request from the same initialized client has identical effective access. Review the actual request context and keep administrative clients separate from ordinary user paths. Source

Our review asks where each privileged key is stored, which server routes can use it, and how those routes authorize the caller before touching user data. Server-side storage alone is not the entire answer. An unrestricted server endpoint can still perform an administrative action for the wrong user. Test that path independently of browser-to-database RLS.

6. Review views and privileged functions separately

Supabase warns that views can bypass RLS because they are commonly created by a privileged owner. For Postgres 15 and later, its documented option security_invoker = true makes a view respect the underlying table's RLS when called by anon and authenticated. On older versions, the guidance is to revoke access from those roles or keep the view in an unexposed schema. Source

The Security Definer View advisor explains why this surprises teams: the view uses its creator's permissions rather than the querying user's. A view created in the public schema can therefore expose data that the base-table policy was intended to withhold. Test the API response from the view itself, not only a direct query against the underlying table. Source

Functions need their own review too. Supabase's API guide says RLS does not apply to functions as a separate access gate, so EXECUTE should be granted only to roles that need the function. Its RLS guide warns about exposed security definer functions and recommends a pinned search_path with qualified object names. Privileged functions require deliberate design, not a blanket assumption that a table policy covers every route. Source Source

7. Check where authorization claims come from

Supabase cautions against using user-editable metadata for authorization. raw_user_meta_data can be updated by the authenticated user, while raw_app_meta_data cannot be updated through that user path. It also notes that JWT claims can be stale: removing team membership from stored app metadata is not reflected by auth.jwt() until the user's token refreshes. Source

Our recommendation is to test permission removal as carefully as permission creation. Remove a member, then exercise the old session against protected data and document the behavior. Decide what your product requires for immediate revocation. Do not promise instant removal based only on changing one metadata field if the authorization path still reads an earlier token.

8. Make policy tests part of the launch gate

Supabase's RLS guide includes database policy tests and the supabase test db workflow. It distinguishes two common denial outcomes: a with check violation raises an error, while a using filter can simply match zero rows. A test that expects every unauthorized action to throw an exception can miss the actual result or report a correct policy as broken. Source

Our release gate combines policy tests, API tests with real test-user roles, and a final state check after each attempted write. Preserve the test cases beside the migrations so a future AI-generated feature cannot quietly remove the boundary. Add performance checks after correctness is established, rather than replacing an expensive policy with unrestricted access.

For the broader launch review, read our guide to auditing vibe-coded apps before launch. For help moving a prototype toward a release, see vibe coding for founders. This checklist is one part of that work, not a certificate that your entire application is secure.