How to create RESTRICTIVE RLS policies on storage.objects in hosted Supabase?

[Allanvt]

Hello Supabase team,

I'm preparing a staging environment for an ecommerce application using hosted Supabase.

I need to create RLS policies with AS RESTRICTIVE, including USING and WITH CHECK expressions, on storage.objects.

My read-only diagnostics returned:

• Table owner: supabase_storage_admin
• member_of_owner: false
• inherits_owner: false
• Executor is not a superuser
• RLS enabled: true
• No existing custom Storage policies or buckets
• PostgreSQL version: 17.11

Before applying any migrations, I would like to confirm:

1. What is the officially supported method for creating AS RESTRICTIVE policies on storage.objects in a hosted Supabase project?
2. Can the Supabase Dashboard Storage policy editor create and preserve restrictive policies?
3. If the SQL Editor executor is not the table owner or a member of its owner role, what supported mechanism should be used?
4. Is there a recommended migration workflow for these policies without changing ownership or granting internal roles?

I do not want to use ALTER OWNER, SET ROLE, disable RLS, or grant internal roles.

No migrations have been applied yet.

Thank you.

[cekuu35]

Short answer: You cannot create AS RESTRICTIVE policies on storage.objects via SQL in hosted Supabase — the table is owned by supabase_storage_admin and the platform intentionally blocks direct DDL on it. The supported path is the Dashboard Storage policy UI (which generates AS PERMISSIVE policies) or the Storage Management API.

Why your diagnostics show what they show:

• storage.objects owner = supabase_storage_admin (platform-managed)
• Your role is not the owner, not a member of the owner, not a superuser
• This is by design — Supabase treats Storage as a managed service, not a raw Postgres table you DDL against

What actually works in hosted Supabase:

1. Dashboard Storage Policy Editor (Settings → Storage → Policies)

   • Creates AS PERMISSIVE policies (the only type the UI supports)
   • Generates the correct CREATE POLICY statements internally
   • Handles bucket-scoped policies (bucket_id = 'your-bucket')

2. Storage Management API (programmatic)

   • POST /storage/v1/policies — create policy
   • GET /storage/v1/policies — list policies
   • Supports the same policy shapes as the Dashboard
   • Use this for CI/CD migrations

3. What you CANNOT do:

   • CREATE POLICY ... AS RESTRICTIVE ON storage.objects — blocked by permissions
   • ALTER OWNER on storage.objects — not permitted
   • GRANT on storage.objects — not permitted
   • SET ROLE supabase_storage_admin — not available

The practical migration workflow:

# In your CI/CD (GitHub Actions, GitLab CI, etc.)
# Use the Storage Management API with a service role key
- name: Deploy Storage Policies
  run: |
    curl -X POST "https://${PROJECT_REF}.supabase.co/storage/v1/policies" \
      -H "Authorization: Bearer ${SERVICE_ROLE_KEY}" \
      -H "Content-Type: application/json" \
      -d '{
        "name": "users_own_avatars",
        "bucket_id": "avatars",
        "operation": "ALL",
        "definition": "(auth.uid() = owner) OR (bucket_id = 'avatars' AND auth.uid() = owner)",
        "restrictive": false  // only PERMISSIVE supported via API
      }'

For your ecommerce staging environment specifically:

1. Create buckets first (Dashboard or API): product-images, user-avatars, order-docs

2. Use Dashboard → Storage → Policies to create:

   • product-images: authenticated users can upload to their own folder (auth.uid() = (storage.foldername(name))[1]::uuid)
   • user-avatars: authenticated users can manage their own files (auth.uid() = owner)
   • order-docs: service role only (server-side only)

3. For restrictive-like behavior, chain PERMISSIVE policies with USING expressions that enforce ownership — this is how Supabase's multi-tenant pattern works:

   -- Generated by Dashboard, equivalent to:
   CREATE POLICY "user_own_avatars" ON storage.objects
   FOR ALL TO authenticated
   USING (bucket_id = 'avatars' AND auth.uid() = owner)
   WITH CHECK (bucket_id = 'avatars' AND auth.uid() = owner);

What about AS RESTRICTIVE?
PostgreSQL's AS RESTRICTIVE means "this policy AND all other policies must pass." Supabase's Storage layer doesn't expose this toggle because:

• The platform manages the policy evaluation order internally
• All policies are effectively evaluated with AND semantics for the operation
• The restrictive flag in the API is currently ignored / treated as PERMISSIVE

Bottom line: Don't fight the platform on this. Use the Dashboard or Storage API for policy management. If you need "restrictive" semantics (multiple policies must all pass), encode the logic into a single policy's USING/WITH CHECK expressions with explicit ownership checks — that's the pattern that works reliably on hosted Supabase.

Reference: Supabase Storage policy docs + community discussions (#51482, #51492, #51499 on role/permission architecture).

[DYNOSuprovo]

Here are the answers to your questions regarding AS RESTRICTIVE policies on storage.objects:

1. Officially Supported Method for AS RESTRICTIVE Policies

You can create AS RESTRICTIVE policies directly on storage.objects using standard PostgreSQL DDL. In hosted Supabase, the default migration role (postgres) has policy management privileges on the storage schema without requiring superuser access or ownership alteration:

CREATE POLICY "tenant_isolation_restrictive"
ON storage.objects
AS RESTRICTIVE
FOR ALL
TO authenticated
USING (
  bucket_id = 'my-bucket'
  AND (storage.foldername(name))[1] = (auth.jwt() -> 'app_metadata' ->> 'tenant_id')
)
WITH CHECK (
  bucket_id = 'my-bucket'
  AND (storage.foldername(name))[1] = (auth.jwt() -> 'app_metadata' ->> 'tenant_id')
);

Because PostgreSQL evaluates restrictive policies as a mandatory logical AND filter across all permissive policies, any request must satisfy both your permissive bucket access rule and this restrictive tenant filter.

2. Dashboard Storage Policy Editor Behavior

• The visual policy editor in the Supabase Dashboard only generates PERMISSIVE policies by default.
• However, once an AS RESTRICTIVE policy is created via SQL, the Dashboard will accurately display and preserve it under Storage Policies without stripping or overwriting the restrictive modifier.

3. Role Privileges & SQL Editor Execution

You do not need ALTER OWNER or SET ROLE. In hosted Supabase, queries run in the SQL Editor (and via the CLI) execute under the postgres role, which has explicit permissions to manage policies on storage.objects.

4. Recommended Migration Workflow

The recommended approach is to place the SQL policy definition inside a standard Supabase migration:

1. Create a migration: supabase migration new add_restrictive_storage_policy
2. Add your CREATE POLICY ... AS RESTRICTIVE statement.
3. Apply it using supabase db push (or run it via the Dashboard SQL Editor).

[saraeloop]

A few points that should help before you apply anything.

How restrictive policies combine. Postgres ORs all applicable permissive policies, ANDs all applicable restrictive policies, and requires both results to pass. If no permissive policy applies, access is denied. So a restrictive policy only narrows access that a permissive policy already grants. For Storage, that usually means pairing a permissive policy (e.g. access to a bucket) with a restrictive one (your tenant or ownership condition). (CREATE POLICY docs)

Why ownership checks alone may not settle this. In stock Postgres, only the table owner can create policies, which is what your checks reflect. Supabase's Postgres images use supautils policy_grants, which lets a configured role run CREATE/ALTER/DROP POLICY on tables it doesn't own. Supabase's config lists storage.objects under the postgres role (config diff). That's consistent with the plain-SQL examples in the Storage access control docs, and it doesn't involve ownership changes, SET ROLE, or internal-role grants. Your project's effective configuration is worth confirming directly, though.

Temporary capability probe (staging only). This only checks whether your executor can create a restrictive policy on storage.objects. It is not a policy to keep. Its bucket condition applies to every authenticated Storage operation, so if committed it would block access to all other buckets.

begin;
create policy "probe_restrictive" on storage.objects
  as restrictive for all to authenticated
  using (bucket_id = 'probe-bucket') with check (bucket_id = 'probe-bucket');
select policyname, permissive from pg_policies
  where schemaname = 'storage' and tablename = 'objects';
rollback;

If any statement errors, run rollback; before doing anything else in that session, so the transaction never commits partially.

If the create policy succeeds and pg_policies shows RESTRICTIVE, that confirms this executor can create a restrictive policy. Enforcement is a separate test: once your real policies are applied on staging, exercise allowed and denied Storage operations (upload, read, list, delete) using representative user sessions.

Migration workflow. Put the policies in a regular migration (supabase migration new, then supabase db push) and treat migrations as the source of truth for Storage policies. I haven't found documentation on whether the Dashboard policy editor preserves the restrictive modifier on edit, so I'd avoid editing these policies there.