"Row-level security policy for table objects" on upload

Your app uploads a file. It worked in your builder's preview, or it worked last week, and now every attempt comes back with a sentence about row-level security:

new row violates row-level security policy for table "objects"

Most of that sentence will look familiar if you have already been through this on one of your own tables. The last word is the part that is different, because objects is not a table you made.

Here is the part that guide after guide gets wrong: the first fix you will find is to make the bucket public, and it does nothing to uploads. Supabase's own documentation says as much in one line. Flipping that toggle leaves the upload refused and opens the files that were already in there.

What "new row violates row-level security policy for table objects" means

Your upload reached Supabase Storage, Storage asked the rules on a table called storage.objects whether that file was allowed in, found none that said yes, and refused.

The row in the message is real. Storage keeps one row in storage.objects for every file it holds, carrying the file's name, which bucket it is in and who put it there. Writing a file means writing that row, so the rules on that table decide whether the upload happens at all. Nothing was lost: no file was stored, and the rest of the bucket sits exactly as it did a minute ago.

The wording comes from Postgres, the database engine underneath Supabase, which is why it reads like machinery. It carries the code 42501, the same code you get when a save into one of your own tables is refused.

Why the message names "objects" and not your bucket

Because Storage keeps the rules for every bucket in your project on that one table.

A bucket organises files. It does not hold rules of its own, and there is no policy editor attached to it. storage.objects is where the rules live, for all of your buckets at once, and bucket_id is a column on it. So a rule that says "only in the avatars bucket" is written as a condition on that column.

This is also why the table rule you wrote last week did not help. A rule on profiles is a rule about rows in profiles, and a file is a row in storage.objects.

Do I need to make the bucket public to upload?

No. Two different questions sit behind one bucket, and the toggle only answers one of them. Who may take a file out is what public decides. Who may put a file in is what your error is about, and Supabase's documentation is explicit that the setting does not reach it. From the page describing the two kinds of bucket, read on 11 October 2026:

Access control is still enforced for other types of operations including uploading, deleting, moving, and copying.

What public does do is just as plainly stated on that page: anyone who has the address of a file can open it without signing in. That is the whole of the setting.

So flipping it leaves you in the one state nobody wants. The upload is still refused, because uploading was never what the setting controlled, and the files that were already in the bucket can now be opened by anybody who has their addresses. What a public bucket actually costs you is a separate question from this error, and worth reading before you touch the switch.

What a bucket actually checks when you upload

One rule, and its name is insert.

Supabase's access-control page puts the default plainly: Storage does not allow any uploads to buckets without policies, and you allow operations selectively by writing them on storage.objects. Then it names the one you need:

For example, the only RLS policy required for uploading objects is to grant the INSERT permission to the storage.objects table.

There is a second half to that, and it is the commonest reason an insert rule does not clear the error:

To allow overwriting files using the upsert functionality you will need to additionally grant SELECT and UPDATE permissions.

If your upload passes upsert: true, which asks Storage to replace a file of the same name when one is already there, then an insert rule on its own is not enough. Replacing a file is three questions rather than one: may you add this row, may you see the row that is there, and may you change it.

You do not have to write all five. Write the ones your app actually does, which for most uploads is the first row and sometimes the second.

The rule that lets your app upload, and only your app

Name the bucket, and say who the rule is for.

The documentation's own starting point restricts an upload to one bucket and to signed-in visitors:

create policy "Allow authenticated uploads"
on storage.objects
for insert
to authenticated
with check (bucket_id = 'my_bucket_id');

to authenticated is the part worth not skipping. It means the rule applies to visitors who are signed in; leave it out and the rule applies to everybody, strangers included.

For anything belonging to one particular person, the version Supabase publishes puts each person's files in a folder named after them:

create policy "Allow authenticated uploads"
on storage.objects
for insert
to authenticated
with check (
  bucket_id = 'my_bucket_id' and
  (storage.foldername(name))[1] = (select auth.jwt()->>'sub')
);

storage.foldername(name) splits a stored file's path into its folders, so [1] is the first one. auth.jwt()->>'sub' is the id of whoever is signed in and making the request. Read together, the two lines say that you may put a file in the folder named after you, in that bucket, and nowhere else.

Both of those are Supabase's examples rather than ours, read on 11 October 2026, with my_bucket_id left where they left it so you can see which part is the name of your own bucket.

If you would rather see the result from outside, our free scan asks your live project which of your buckets will hand their contents to a stranger. It takes about 20 seconds and needs no account: scan your app.

What a read rule hands over without being asked

Listing a bucket and downloading from it are the same privilege, so a rule written to make your downloads work also makes the bucket's contents listable.

Supabase's helper-function page says it directly: a single SQL privilege such as SELECT is used by multiple Storage actions. The access-control page then warns about the specific case, under an example that opens a bucket of avatars to everybody:

The allow_any_operation() filter is critical here as without it users would be able to list the bucket contents.

That is the gap we measure from outside. We have scanned 8,435 live apps that name a Supabase project. The bucket check got an answer out of 4,703 of them, and 792 of those answered a list request from us with the names of what was inside, with nobody signed in. That is about one in six of the apps we could ask.

A name is often all somebody needs, because a bucket that lists saves a stranger from guessing filenames. invoice-2026-03-hannah.pdf says who the file belongs to before anybody opens it.

The fix Supabase documents is to say which Storage action the rule is for:

create policy "Allow users to list their own objects"
on storage.objects
for select
to authenticated
using (
  storage.allow_only_operation('object.list')
  and owner_id = (select auth.uid()::text)
);

storage.allow_only_operation and its sibling storage.allow_any_operation are how a select rule narrows itself to one of the actions that share the privilege. Without one of them, a rule you wrote so that your app could show a picture is also a rule that will read out everything in the bucket.

Whether a listable bucket is a problem for your app depends on what is in it, which is a question the scan result cannot answer for you.

When public is the right answer

When the files are meant to be seen by anybody who asks, which is a real category, and Supabase lists its own examples of it.

Supabase's own example use cases for a public bucket are profile pictures, public media and blog post content. Those are files your app shows to a visitor who has not signed in, and serving them from a public bucket is faster as well, because the two kinds of bucket are cached differently.

For the other kind, the documentation names two ways to get a file out of a private bucket: a download carrying the signed-in person's token, or a signed link that works for a limited time. Both of those keep the decision with your rules rather than with whoever found the address.

Keeping the bucket right after today

Two things move after the rules are correct: somebody flips the toggle while chasing an unrelated bug, and a file goes missing.

Reeve Monitor runs the nine outside checks again for you:

• all nine checks every hour, on up to three apps, including the bucket listing one
• whether the app is up, every 60 seconds
• a message when a result changes, so a bucket that opened last night does not wait for you to look
• a monthly report of what it saw

Reeve Care keeps a copy of what is in there:

• an encrypted copy of your Supabase database every night, kept where your project cannot reach it
• each copy verified before it counts, by counting the rows in every table
• your uploaded files as well, once you connect a Storage credential
• a one-click restore when you need one
• everything Monitor does

Both are on the pricing page, which is sometimes below the list figure and never above it.

What to do today

Start with the bucket the error came from, then look at the other buckets in the same project, because a rule written broadly once tends to have been pasted twice. The 10-minute security checklist covers what else is usually left open in a newly launched app, and the Supabase safety guide goes through the rest of what a stranger can reach.