Storage: upload rejected with RLS violation that no policy can satisfy (TO public also fails)

[kumarbrijesh-900]

SUBJECT
Storage: upload rejected with RLS violation that no policy can satisfy
(project mjrbytfvesgvbuxyoidp)

SUMMARY

All uploads to our Storage bucket have failed since 23 April 2026 with
"new row violates row-level security policy". We have eliminated every
client-side and database-side cause we can test, including adding a
temporary INSERT policy scoped TO public — which covers every PostgreSQL
role. The insert still failed identically. Within PostgreSQL there is no
role for which that policy would not have permitted the row, so we believe
the statement is not being evaluated against this project's
storage.objects policy set. We are asking you to check Storage's database
routing/connection configuration for this project.

IMPACT

Logo, digital signature and payment QR upload are all non-functional and
have been for five months. They share one code path. There is no
workaround for our users.

ENVIRONMENT

Project ref mjrbytfvesgvbuxyoidp (Free tier)
Bucket professional-assets (public)
Endpoint mjrbytfvesgvbuxyoidp.supabase.co
(no custom domain, proxy or CDN in front)
Client supabase-js via @supabase/ssr, browser-direct upload

REPRODUCTION

POST /storage/v1/object/professional-assets/logos/--cropped.png

Response 400:
{ "statusCode": "403",
"error": "Unauthorized",
"message": "new row violates row-level security policy",
"code": "AccessDenied" }

Failing request timestamp (UTC):

Last successful uploads: 23 April 2026, four objects written between
15:35 and 15:43 UTC. Every attempt since has failed. We changed no
policy, grant or trigger in that window.

ELIMINATED — CLIENT SIDE

Authorization header present and correct on the actual failing request
(read from DevTools, not application state):
apikey: sb_publishable_...
Authorization: Bearer eyJ... <- user JWT, not the publishable key

Token claims decoded at time of failure:
role "authenticated" (top-level claim)
aud "authenticated"
sub present
exp ~2566s in the future, not expired
alg ES256, kid matches the project's CURRENT JWT signing key

Reproduced on a token seconds old after a hard reload — identical failure,
so this is not token staleness.

ELIMINATED — DATABASE SIDE

Three INSERT policies tested on storage.objects, each retried against the
same upload. All three failed identically:

  TO authenticated   WITH CHECK (bucket_id = 'professional-assets')
  TO anon            WITH CHECK (bucket_id = ... AND name LIKE 'logos/%')
  TO public          WITH CHECK (bucket_id = ... AND name LIKE 'logos/%')

The anon and public policies were temporary and have been dropped.

Schema state, read from the catalog:
relrowsecurity = true
relforcerowsecurity = false
No restrictive policies on storage.objects
authenticated holds INSERT grant on storage.objects
storage.prefixes does not exist in this project
Exactly two non-internal triggers, neither on INSERT:
protect_objects_delete BEFORE DELETE FOR EACH STATEMENT
update_objects_updated_at BEFORE UPDATE FOR EACH ROW

Bucket professional-assets exists, is public, and the request path and
bucket_id both resolve to it. Object names are timestamped, so every
insert is new — no upsert or conflict path is involved.

WHY WE BELIEVE THIS IS SERVICE-SIDE

A committed policy of

  FOR INSERT TO public WITH CHECK (bucket_id = 'professional-assets'
                                   AND name LIKE 'logos/%')

permits the row for every ordinary PostgreSQL role. The predicate matched
the bucket and the path of the object being written. The same RLS error
was still returned. No role-resolution outcome explains that.

WHAT WE ARE ASKING FOR

1. Confirm which database and schema the Storage service is writing to
   for this project, and whether it matches the one exposed via the SQL
   editor and the Postgres connection string.
2. Confirm whether the Storage service is holding a stale or inconsistent
   database connection or configuration for this project.
3. Confirm whether any platform change around 23 April 2026 could account
   for the cutoff.

NOTES

The in-dashboard AI assistant triaged this first and reached the same
conclusion: that under the documented authorisation model the effective
role should be "authenticated", the insert should pass, and the remaining
explanation is a Storage routing or authorisation-layer defect. We are
escalating on that basis rather than as a configuration question.

No credentials are included in this report and none should be needed. We
can supply redacted request/response screenshots on request.

[somuai]

The root cause of this failure is that PostgreSQL requires a matching SELECT policy on storage.objects during an INSERT ... RETURNING operation, even when your INSERT policy is completely satisfied.

---

Why PostgreSQL Rejects the Insert with an RLS Violation

When supabase-js uploads an object via POST /storage/v1/object/..., the Supabase Storage backend (storage-api) writes the binary payload to storage and then persists the metadata record to PostgreSQL by executing:

INSERT INTO storage.objects (bucket_id, name, owner, metadata, version, ...)
VALUES ($1, $2, $3, $4, $5, ...)
RETURNING *;

In PostgreSQL, Row-Level Security evaluation rules dictate that when an INSERT statement includes a RETURNING clause:

1. The WITH CHECK clause of the table's INSERT policies is evaluated on the proposed new row.
2. If WITH CHECK passes, PostgreSQL additionally evaluates the table's SELECT (USING) policies on the inserted row before returning it to the client.
3. If no SELECT policy allows the current role to read that row, PostgreSQL throws:

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

Because you tested and verified only INSERT policies on storage.objects, the RETURNING * projection was rejected by PostgreSQL under RLS, yielding the exact 403 AccessDenied response.

---

How to Fix

Add a corresponding SELECT policy on storage.objects alongside your INSERT policy. Run the following in your Supabase Dashboard SQL Editor:

-- 1. Ensure the SELECT policy exists so the RETURNING clause succeeds
CREATE POLICY "Allow authenticated read professional-assets"
ON storage.objects
FOR SELECT
TO authenticated
USING (bucket_id = 'professional-assets');

-- 2. Ensure the INSERT policy is scoped as desired
CREATE POLICY "Allow authenticated upload professional-assets"
ON storage.objects
FOR INSERT
TO authenticated
WITH CHECK (bucket_id = 'professional-assets');

If your bucket is public and unauthenticated visitors also need to view the files via the public CDN URL or read metadata, you can scope the SELECT policy TO public:

CREATE POLICY "Allow public read professional-assets"
ON storage.objects
FOR SELECT
TO public
USING (bucket_id = 'professional-assets');

---

Verification

Once the FOR SELECT policy is added to storage.objects, the INSERT ... RETURNING * query executed by the storage service will satisfy both the WITH CHECK and USING security contexts, and your logo, signature, and QR code uploads will succeed immediately.

[kumarbrijesh-900]

Solved Thanks @somuai — the explanation was exactly right.
Root cause: Supabase's storage-api persists object metadata with:```sql
INSERT INTO storage.objects (bucket_id, name, owner, metadata, version, ...)
VALUES (...) RETURNING *;