How to Handle 403 Forbidden Errors in Supabase Storage

Open your browser's developer tools and check the Network tab when the 403 error occurs. Look at the request URL and HTTP method. A POST to /storage/v1/object means an upload is failing. A GET to /storage/v1/object means a download or URL generation is failing. A DELETE means a file removal is blocked. Note the bucket name and file path from the URL — you will need these to write the correct policy. Also check whether the request includes an Authorization header with a valid JWT token. If the header is missing, your Supabase client is not authenticated.

In the Supabase Dashboard, go to Storage and click on your bucket. Check whether it is set to Public or Private. Public buckets allow anyone to read files without authentication — but uploads and deletes still require RLS policies. Private buckets require RLS policies for ALL operations including reads. If you intended the bucket to be publicly readable, toggle it to Public in the bucket settings. If it should remain private, you need SELECT policies on storage.objects for downloads.

1-- Check bucket settings via SQL
2select id, name, public from storage.buckets;

Open the SQL Editor in your Supabase Dashboard and create the appropriate policies. The storage.objects table has columns including bucket_id (the bucket name), name (the full file path), and owner (the user ID who uploaded the file). Use auth.uid() to scope access to the authenticated user. The storage.foldername(name) function extracts path segments, which is useful for user-scoped folder patterns where files are stored under the user's ID.

1-- Allow authenticated users to upload files to their own folder
2create policy "Users can upload to own folder"
3on storage.objects for insert
4to authenticated
5with check (
6  bucket_id = 'my-bucket'
7  and auth.uid()::text = (storage.foldername(name))[1]
8);
9
10-- Allow authenticated users to read their own files
11create policy "Users can read own files"
12on storage.objects for select
13to authenticated
14using (
15  bucket_id = 'my-bucket'
16  and auth.uid()::text = (storage.foldername(name))[1]
17);
18
19-- Allow authenticated users to delete their own files
20create policy "Users can delete own files"
21on storage.objects for delete
22to authenticated
23using (
24  bucket_id = 'my-bucket'
25  and auth.uid()::text = (storage.foldername(name))[1]
26);

If your use case requires public read access without user authentication (for example, a public image gallery), you can create a SELECT policy that grants access to both the anon and authenticated roles. This is an alternative to making the entire bucket public and gives you finer control — you can make some paths public and others private within the same bucket.

1-- Allow anyone to read files in the 'public' folder
2create policy "Public read access for public folder"
3on storage.objects for select
4to anon, authenticated
5using (
6  bucket_id = 'my-bucket'
7  and (storage.foldername(name))[1] = 'public'
8);

After creating the policies, test each operation that was failing. Make sure you are signed in as an authenticated user when testing operations that target the authenticated role. Use the Supabase JS client to upload a file, retrieve its URL, and delete it. Check the browser console and Network tab to confirm you no longer receive 403 errors.

1import { createClient } from '@supabase/supabase-js'
2
3const supabase = createClient(
4  process.env.NEXT_PUBLIC_SUPABASE_URL!,
5  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
6)
7
8// Test upload (user must be signed in)
9const { data, error } = await supabase.storage
10  .from('my-bucket')
11  .upload(`${userId}/test.txt`, new Blob(['hello']), {
12    contentType: 'text/plain',
13  })
14
15if (error) console.error('Upload failed:', error.message)
16else console.log('Upload succeeded:', data.path)

Go to Authentication > Policies in the Supabase Dashboard and filter for the storage.objects table. You should see all the policies you created. Verify that each policy targets the correct operation (INSERT, SELECT, DELETE), the correct roles (authenticated, anon), and references the correct bucket_id. If you have conflicting policies or policies with typos in the bucket name, they will silently fail to match and the 403 error will persist.

1-- List all policies on storage.objects
2select policyname, cmd, roles, qual, with_check
3from pg_policies
4where tablename = 'objects' and schemaname = 'storage';