How to create a RESTRICTIVE RLS policy on storage.objects without owner privileges?

[pereiradavid24]

Hi Supabase community,

I'm developing a CRM application using Supabase Storage and PostgreSQL.

We have a private Storage bucket containing client documents. Currently, existing PERMISSIVE policies allow authenticated users to access objects in this bucket without sufficient per-document restrictions.

We want to deny direct client access to this bucket while preserving authorized server-side access through our backend using the service_role key.

Our proposed solution is:

CREATE POLICY client_documents_server_only
ON storage.objects
AS RESTRICTIVE
FOR ALL
TO anon, authenticated
USING (bucket_id <> 'client-documents')
WITH CHECK (bucket_id <> 'client-documents');

However, our SQL Editor session has the following properties:

• Current role: postgres
• storage.objects owner: supabase_storage_admin
• Superuser: false
• BYPASSRLS: true
• Membership in the owner role: false
• Inherited owner privileges: false
• Authority to CREATE POLICY: false

We would like to know:

1. What is the officially supported way to create a RESTRICTIVE policy on storage.objects under these permissions?
2. Does the Supabase Storage Policies dashboard support RESTRICTIVE policies?
3. Is there an alternative supported approach to deny direct access by authenticated users without changing system-table ownership or elevating database privileges?
4. Would the recommended solution preserve server-side access using service_role?

We have deliberately avoided changing ownership, granting elevated privileges or attempting unsupported workarounds.

Any guidance or references to official documentation would be appreciated.

Thank you!

[GaryAustin1]

There should be no restrictions on adding policies with SQL. The SQL editor adds them just fine This shows using SQL to create policies. https://supabase.com/docs/guides/storage/security/access-control

Creating restrictive policies should be doable but more complicated because of the way they are handled in Postgres. You have to have permissive policies first and then you use restrictive policies to reduce access. This seems like it would be especially complicated with buckets involved as all policies are on the same table and just use where clauses to apply to different buckets.

I would just use permissive policies to only allow storage access to service_role if that is what you want. Anon and authenticated do not have access by default unless you allow them.

[mateuszingano]

if the sql editor won't let you create policies on storage.objects, you probably don't need a restrictive one anyway.

permissive policies get OR'd together, so the only reason authenticated can reach client-documents is that one of your existing permissive policies matches it. edit those (Storage > Policies in the dashboard is fine for that) and add bucket_id <> 'client-documents' to their conditions. once nothing permissive matches the bucket, anon/authenticated get nothing from it, since deny is the default.

to see which ones match today:

select policyname, roles, cmd, qual, with_check
from pg_policies
where schemaname = 'storage' and tablename = 'objects';

on 4: yes, service_role bypasses RLS, so your backend keeps working whatever policies you end up with.

worth testing after with a normal user session: list/download on that bucket should fail.

[cekuu35]

Quick note on RESTRICTIVE policies: they only narrow an existing PERMISSIVE allowance. For deny-all-client-access + service_role-backend, drop the permissive policies (or scope to service_role) rather than stack a restrictive filter. service_role bypasses RLS by default.

Free read-only RLS audit SQL (9 queries, MIT, nothing leaves your machine): https://github.com/cekuu35/supabase-rls-audit
Full kit ($29): https://cengokurtoglu.gumroad.com/l/supabase-rls-audit-kit