Your application is working. Customers can sign in, create projects and upload files. Then a larger prospect asks for an independent security assessment before connecting its data.

The question you need to answer is specific: can the application enforce each customer’s permissions through every route to that data? A successful demonstration of the product does not establish that boundary.

Start with the customer boundary

Suppose your application serves two consulting firms. Each has an owner, an administrator and ordinary members. Both upload client documents and generate reports. Before testing, write down which actions each role should be allowed to perform, including what happens when someone belongs to both firms.

Build test organizations with synthetic records and accounts for those roles. Include an unauthenticated visitor, an invited user who has not joined, and a former member. An audit can then compare the intended rules with observed behavior without needing to expose real customer documents.

Check more than document viewing. Who can change an organization identifier, invite an administrator, replace a file, export a report or remove another member? A customer boundary can fail through a write operation even when ordinary reads are correctly restricted.

Customer access is a matrix. Define expected access for each role and customer organization, then test both permitted and denied actions.
Define expected access for each role and customer organization, then test both permitted and denied actions.

Inspect the paths around your RLS policies

Supabase’s documentation explains that privileged database access can bypass row-level security, and that views require particular care. Having RLS enabled on a table therefore does not settle how every application path behaves. Review the permissions of the caller and the database objects involved. Supabase RLS documentation.

Consider a report-export function. The browser sends a project identifier to a server function, which retrieves the project using elevated permissions. That function must establish that the requesting user can export that specific project. Authentication alone answers who made the request; it does not establish ownership of the supplied project.

During an authorized review, test that operation using the second organization’s synthetic project. Record whether the request is rejected and whether any job, file or download link is created despite the rejection. The important result is the entire business operation, not just its HTTP status.

Follow all routes to the data. Normal queries, privileged functions and scheduled jobs can use different permissions. Assess each agreed route.
Normal queries, privileged functions and scheduled jobs can use different permissions. Assess each agreed route.

Treat files and functions as separate access paths

A protected record may reference a document stored elsewhere. Review who can upload, list, replace and download that document, and whether its access follows the intended customer boundary. Supabase Storage has its own access-control configuration built around policies. Storage access-control documentation.

Also examine the application’s server functions. A webhook, scheduled task and user-facing endpoint have different callers and should not automatically share the same authorization assumptions. Supabase documents several authentication approaches for Edge Functions; the review must establish which approach each deployed function actually uses. Edge Function security documentation.

An illustrative test would follow an export from request to completion: user authorization, selected organization, background task, generated file and final download. A check confined to the initial database query could miss a later mix-up.

A record and its file have separate paths. A protected database record does not by itself establish the access rules for a linked document.
A protected database record does not by itself establish the access rules for a linked document.

Test permission changes, not just initial access

Applications change while sessions and jobs remain active. Remove a user from an organization, demote an administrator and transfer project ownership. Then check the remaining access through the agreed interfaces.

Decide the intended behavior before declaring a failure. A previously issued download link may deliberately remain usable for a limited period. A background job might be permitted to finish, or it might require cancellation. The audit should compare the implementation with a documented business rule and explain any residual exposure.

Permissions change during a session. Assess what remains accessible after a role or membership change, including work already in progress.
Assess what remains accessible after a role or membership change, including work already in progress.

Ask for evidence an engineer can reproduce

A useful finding identifies the role used, the affected action, the expected restriction and the observed result. It should describe the business impact, show redacted supporting evidence and point to the control that needs changing.

For example: an ordinary member of test organization A could export a synthetic document owned by test organization B through a named function. That is actionable. A generic warning that authorization “could be improved” leaves the development team to rediscover the issue.

The report should also name the application version, test period, roles examined and important exclusions. Buyers can then understand what the assessment covers. A clean result for selected paths is not a guarantee about every feature or future release.

Make the finding reproducible. A useful finding connects a tested permission failure to its evidence, remediation and retest result.
A useful finding connects a tested permission failure to its evidence, remediation and retest result.

Scope the assessment before promising a deadline

Prepare an architecture sketch, a role list, a list of exposed functions, the main file flows and access to an appropriate test environment. Explain custom integrations and sensitive actions, including billing or administrative tasks.

The best time to commission the assessment is while engineers can still correct findings before the customer’s deadline. Agree the scope, report delivery and retest window in writing. Keep the security review tied to the product you are delivering and the permissions your customers rely on.

Need an independent review of your Supabase application? Request a written audit scope covering your roles, customer boundaries and critical data paths. Build your audit scope ↗

Scope the application before quoting. The scope follows business permissions and data paths, rather than page count alone.
The scope follows business permissions and data paths, rather than page count alone.

Published 28 October 2026. Original Atlant Security analysis. Scenarios and diagrams are illustrative, not client findings. Platform references are linked beside the relevant guidance.