Supabase security checks before you add more customers

Start with what one customer must never see

If your Supabase product has paying customers, your first security question is practical: can one customer read or change another customer’s information? A working sign-in screen does not answer that. Neither does a reassuring screenshot from the database dashboard.

List the records behind the product’s main customer journey. For a document tool, that might include workspaces, memberships, uploaded files, extracted text, generated results and exports. Include less visible records such as invitations and background jobs. The boundary has to hold across the journey, not only on the first screen.

For each record, name the person or organisation that owns it, who may read it and who may change it. “Anyone who is logged in” is rarely a suitable rule for private customer work. These decisions give your engineer something specific to implement and test.

Signing in is different from belonging to a workspace

Supabase row-level security lets a database policy restrict which rows a caller can access. A policy that permits the authenticated role can still be too broad if it does not check the caller’s relationship to the record. Enabling the feature is the start of the work, not proof that the policy is right.

For a personal product, ownership might follow a user account. For a team product, it may follow workspace membership and the member’s role. Decide how invited members, administrators and removed members should behave. A record owned by a workspace cannot safely depend on whichever user happened to create it.

Ask the engineer to demonstrate two unrelated customer workspaces. A member of Workspace A should not be able to retrieve Workspace B’s records by changing an ID in a request. The check needs to happen where data is accessed, even when the interface never shows that ID.

• A member can read only the workspaces they are permitted to access.
• An invitation does not grant unintended access before acceptance.
• An administrator’s extra permissions are defined explicitly.
• Removing a member has a tested effect on subsequent access, including existing sessions.

Test writes as carefully as reads

A product may hide another customer’s records while still accepting an update to them. Review creation, modification and deletion separately. Test requests directly through the same application interfaces a customer uses, rather than assuming a disabled button is protection.

In Supabase policy design, an existing-row check and a resulting-row check solve different problems. Ask what prevents an allowed update from moving a record into another workspace or assigning a different owner. Ask the equivalent question when creating a new record.

Also decide which fields customers must never control. Subscription status, administrative roles and a paid-credit balance should not become editable merely because they sit beside a user’s own profile fields. Server-managed values may need a separate operation or data structure.

A useful test uses a valid account and an invalid change. Try to create a document under another workspace, change its workspace after creation, promote a normal member and delete another customer’s object. The expected rejection should be clear, and no forbidden data should change.

A server-only key does not make an endpoint safe

Supabase’s API-key guidance distinguishes publishable keys from elevated secret keys. Publishable keys can be used in the browser with appropriate permissions. Secret keys, and legacy service-role keys, bypass row-level security and must remain in controlled backend components.

That means a backend using elevated access must enforce the customer’s permissions itself. Moving a query into a server endpoint does not make it safe if the endpoint trusts a workspace ID supplied by the caller. Verify who is calling and whether that person may perform the requested operation before using elevated access.

Inspect the deployed browser bundle and configuration, not just the source file where a key was originally added. Keep elevated credentials out of shipped apps, public repositories and general logs. If a credential has been exposed, restrict the exposure and follow the provider’s rotation procedure; moving it into a new environment variable is not a revocation.

Use elevated access where a genuinely privileged operation needs it. An engineer should be able to explain why a customer-facing request requires that privilege and where its permission check is enforced.

Follow the boundary into files, exports and functions

Database records are only part of the product. Supabase Storage has its own access-control policies. A file path that includes a workspace ID does not, by itself, establish permission. Test reading, uploading, overwriting and deleting customer files with the same unrelated accounts.

An export can accidentally bypass the rules that protect an ordinary screen. So can a background job that accepts a document ID without verifying its owner. Follow the data into generated downloads, sharing links and support tools. Check what a person receives, not merely whether the request returns a successful status.

Supabase’s Data API guidance also distinguishes object privileges from row policies. Review exposed views and database functions separately, especially functions that execute with elevated privileges. Ask which role runs them and which customer records that role can reach.

Keep the scope manageable by tracing one complete sensitive workflow first. For example: upload a document, process it, read the result, export it and delete it. Then repeat that exercise for the next important workflow instead of reviewing disconnected settings.

Ask for a small, repeatable permission test

Create disposable test customers in an isolated test environment. Give them different workspaces and distinctive dummy records so an unexpected result is easy to recognise. Do not run destructive permission tests against real customer data.

Test through the actual customer authentication and request paths. An administrator or database owner in a SQL editor may bypass the restrictions you intend to assess. A successful administrator query says little about what a normal customer can access.

For each operation, record the expected permission, the actual result and whether data changed. An empty result, a rejected request and a leaked record mean different things. The evidence should be detailed enough that another engineer can reproduce the check after a future change.

• Signed out: cannot retrieve private customer records or files.
• Own workspace member: can perform the actions their role permits.
• Unrelated workspace member: cannot read, create, move, overwrite or delete the other workspace’s private data.
• Removed member: loses the intended access through the product’s real session and membership rules.
• Privileged endpoint: rejects an authorised user asking for an unauthorised customer operation.

Keep permission checks with the changes they protect

A new table, function or upload feature can introduce a new route to customer data. Include its privileges, ownership rules and tests in the same change. Check the actual deployed configuration rather than relying on remembered defaults from a tutorial.

Supabase’s production checklist is a useful companion for project access and platform configuration. Review who can administer the project, protect those accounts and remove access that is no longer needed. Application permission tests and project administration protect different parts of the system.

Use automated tests to retain the two-customer checks, and repeat the relevant checks after migrations. Security-advisor findings can help identify issues, but a clean scan cannot tell you whether “editor” should be allowed to invite another administrator. The product’s permission model still needs human decisions.

What to bring to a focused security review

Bring the customer journey, your ownership and role rules, and the places where private data is stored or exported. Ask for evidence that the boundary holds under an unrelated account and after membership changes. If there is a known leak, contain it and investigate the affected records before adding more traffic.

For a product that is already earning revenue, this is often a more useful first step than replacing Supabase. The important question is whether the current product consistently enforces the permissions your customers expect, and what needs to change where it does not.

• Which records and files belong to each customer or workspace?
• Which roles may read, create, edit, share and delete them?
• Which backend requests use elevated access, and what authorises those requests?
• Can the permission tests be repeated after the next release?