storage/access-control

72 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

Access control can be enforced with RLS policies or server code

Access control based on ownership can be enforced in two ways: using RLS policies on storage.objects, or by implementing access control in server code following the same pattern of comparing owner_id with the user's sub claim.

RLS policy example: user can delete only their own objects

This example shows how to create an RLS policy that restricts delete operations to the owner of an object by comparing the object's owner_id field with the 'sub' claim of the JWT: create policy "User can delete their own objects" on storage.objects for delete to authenticated using ( owner_id = (select auth.uid()::text) );

Ownership alone does not provide access control

The ownership of a resource by itself does not provide any access control. Access control must be enforced by implementing policies against storage resources scoped to their owner.

Owner field is deprecated, use owner_id

The Storage schema has 2 fields to represent ownership: 'owner' and 'owner_id'. The 'owner' field is deprecated and will be removed. Use 'owner_id' instead.

Service key resources have no owner

When using the service_key to create a resource, the owner will not be set and the resource will be owned by anyone. This is also the case when creating Storage resources via the Dashboard.

Ownership automatically assigned on resource creation

When creating new buckets or objects in Supabase Storage, an owner is automatically assigned. The owner is the user who created the resource and the value is derived from the 'sub' claim in the JWT. The owner value is stored in the 'owner_id' column.

RLS-style row-level control available for file access in Storage

Supabase Storage supports RLS-style row-level control for file access. This is implemented through RLS policies on the storage.objects table that check the owner_id field and compare it with the authenticated user's identity, allowing fine-grained access control at the individual file level.

Download methods for private buckets

Assets in private buckets can be downloaded using two methods: (1) the download method with an authorization header containing the user's JWT, where the RLS policy determines access, or (2) a signed URL created with createSignedUrl that can be accessed for a limited time.

Private bucket access model requires RLS policies

Private buckets enforce access control via RLS policies on all operations, including downloads. By default, all buckets are private. To download assets from a private bucket, users must either use the download method with a JWT authorization header (with RLS policies determining access based on the user), or use a signed URL created with the createSignedUrl method that can be accessed for a limited time.

Can I use RLS-style row-level control for file access in Supabase Storage?

Yes. RLS policies on the storage.objects table control file access in private buckets. When a user downloads an asset using the download method with a JWT authorization header, the RLS policy determines if that user has access based on their identity. This enables fine-grain access controls per file.

How do storage policies handle public versus private files?

Private buckets enforce RLS policies on all operations including downloads. Public buckets bypass access controls for retrieval and serving of files—anyone with the asset URL can access the file. However, access control is still enforced on other operations (uploading, deleting, moving, copying) in public buckets. Public buckets are more performant than private buckets because they are cached differently via the CDN.

Storage policies and public versus private file access

Storage policies affect caching behavior differently for public and private buckets. Public buckets serve the same cached content to all users, while private buckets require per-user permission checks that prevent cache sharing between users with different security policies.

Give your agent this brain