Supabase RLS Mistakes AI-Built Apps Commonly Miss

Supabase Auth identifies the current user and supplies a JWT to the database API. RLS policies decide which rows that identity can read or modify. Without a correct policy, the presence of a login screen provides no database-level protection.

Start by writing the rule in plain language. Examples: “A member can read projects belonging to their active tenant,” “A client can update only their own intake,” or “Only an owner can view the acquisition pipeline.” If the policy cannot be explained clearly, it is unlikely to be implemented safely.

A product may secure its obvious tables and forget a supporting table introduced later: notifications, attachments, audit records, profile settings or join tables. Because Supabase can expose tables through its generated API, one omission can bypass the privacy implied by the interface.

Inventory every table in exposed schemas. Confirm RLS is enabled, then confirm the relevant roles have no broader grants than intended. Treat new tables as denied by default until their access model is defined.

Many products begin as single-user apps and later add organizations, clients or teams. A policy such as user_id = auth.uid() may no longer represent the business model once records belong to a tenant and users can join or leave that tenant.

Use a membership relationship that includes tenant, user, role and active status. Then scope the protected record to the same tenant. Test what happens when the membership is suspended or deleted.

Filtering a query by the current user or tenant is good application behavior, but it is not the security boundary. A user can alter a browser request, call the generated API directly or discover another route that omits the filter.

The database policy must make the unsafe query return no rows or raise an authorization failure even when the client sends a broader request.

The Supabase service role bypasses RLS. It belongs only in trusted server or Edge Function environments. A variable name beginning with a public prefix, a client-side import or a generated configuration object can expose it unintentionally.

Review the final browser bundle and deployment environment, not only the source file. Rotate the credential immediately if it has ever been shipped to a client environment or public repository.

Database functions can be the right way to perform an atomic privileged workflow. They can also bypass expected policies when SECURITY DEFINER is used without strict validation, a fixed search path and narrow execution grants.

Each privileged function should validate the caller or be callable only from a trusted service boundary. It should accept the minimum identifiers required, derive ownership server-side and fail closed when records do not match.

A project table can be private while its documents remain public. Storage buckets, object paths and signed URLs need the same ownership model as the records they support.

Use server-derived paths where possible. Avoid trusting a client-supplied tenant or user segment. Verify upload, list, read, replace and delete separately because each operation can require a different policy.

A positive test proves that an intended user can access a record. A security review needs negative tests that prove every other user cannot.

Create two users in different tenants and one user with a lower role in the same tenant. Attempt reads and mutations using known record IDs. Repeat the tests through the same browser, API and function paths used by the product.