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

La tua app carica un file. Funzionava nell'anteprima del tuo builder, o funzionava la settimana scorsa, e adesso ogni tentativo torna indietro con una frase sulla row-level security:

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

Quasi tutta quella frase ti suonerà familiare se ci sei già passato su una tua tabella. Quello che cambia è l'ultima parola, perché objects non è una tabella che hai creato tu.

Ecco la parte che guida dopo guida sbaglia: la prima soluzione che troverai è rendere pubblico il bucket, e non fa niente per gli upload. La documentazione di Supabase lo dice in una riga. Quell'interruttore lascia l'upload rifiutato e apre i file che erano già dentro.

Cosa vuol dire "new row violates row-level security policy for table objects"

Il tuo upload è arrivato a Supabase Storage, Storage ha chiesto alle regole poste su una tabella chiamata storage.objects se quel file poteva entrare, non ne ha trovata nessuna che dicesse di sì, e ha rifiutato.

La riga del messaggio esiste davvero. Storage tiene una riga in storage.objects per ogni file che conserva, con il nome del file, il bucket in cui si trova e chi ce l'ha messo. Scrivere un file vuol dire scrivere quella riga, quindi sono le regole di quella tabella a decidere se l'upload avviene. Niente è andato perso: nessun file è stato salvato, e il resto del bucket sta esattamente come un minuto fa.

La formulazione viene da Postgres, il database sotto Supabase, ed è per questo che si legge come meccanica. Porta il codice 42501, lo stesso di un salvataggio rifiutato in una delle tue tabelle.

Perché il messaggio nomina "objects" e non il tuo bucket

Perché Storage tiene le regole di tutti i bucket del tuo progetto su quell'unica tabella.

Un bucket ordina i file. Regole proprie non ne ha, e non c'è nessun editor di policy attaccato a lui. storage.objects è dove vivono le regole, per tutti i tuoi bucket insieme, e bucket_id è una sua colonna. Così una regola che dice "solo nel bucket avatars" si scrive come una condizione su quella colonna.

È anche il motivo per cui la regola di tabella che hai scritto la settimana scorsa non ha aiutato. Una regola su profiles è una regola sulle righe di profiles, e un file è una riga di storage.objects.

Devo rendere pubblico il bucket per poter caricare?

No. Dietro a un bucket ci sono due domande diverse, e l'interruttore ne risponde una sola. Chi può portare fuori un file lo decide pubblico. Chi può metterne dentro uno è il tema del tuo errore, e la documentazione di Supabase è esplicita sul fatto che l'impostazione non arriva fin lì. Dalla pagina che descrive i due tipi di bucket, letta l'11 ottobre 2026:

Il controllo degli accessi continua a essere applicato agli altri tipi di operazione, compresi caricamento, cancellazione, spostamento e copia.

Quello che pubblico fa davvero è detto con la stessa chiarezza su quella pagina: chiunque abbia l'indirizzo di un file può aprirlo senza accedere. L'impostazione non è altro che questo.

Girarlo ti lascia quindi nell'unico stato che nessuno vuole. L'upload resta rifiutato, perché caricare non è mai stato quello che l'impostazione controllava, e i file che erano già nel bucket adesso li può aprire chiunque abbia il loro indirizzo. Quanto ti costa davvero un bucket pubblico è una domanda diversa da questo errore, e vale la lettura prima di toccare l'interruttore.

Cosa controlla davvero un bucket quando carichi

Una regola, e si chiama insert.

La pagina di Supabase sul controllo degli accessi dice chiaramente qual è il comportamento predefinito: senza policy Storage non permette nessun upload in un bucket, e tu autorizzi le operazioni una per una scrivendole su storage.objects. Poi nomina quella che ti serve:

Per esempio, l'unica policy RLS necessaria per caricare oggetti è concedere il permesso INSERT sulla tabella storage.objects.

C'è una seconda metà, ed è il motivo più comune per cui una regola insert non toglie l'errore:

Per consentire la sovrascrittura dei file tramite la funzionalità upsert dovrai concedere in aggiunta i permessi SELECT e UPDATE.

Se il tuo upload passa upsert: true, che chiede a Storage di sostituire un file con lo stesso nome quando ce n'è già uno, allora una regola insert da sola non basta. Sostituire un file sono tre domande invece di una: puoi aggiungere questa riga, puoi vedere quella che c'è, e puoi modificarla.

Non devi scriverle tutte e cinque. Scrivi quelle che la tua app fa davvero, che per la maggior parte degli upload è la prima riga e a volte la seconda.

La regola che fa caricare la tua app, e solo la tua app

Nomina il bucket, e di' per chi vale la regola.

Il punto di partenza della documentazione limita un upload a un bucket e ai visitatori che hanno fatto accesso:

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

to authenticated è la parte da non saltare. Vuol dire che la regola si applica ai visitatori che hanno fatto accesso; toglila e la regola si applica a tutti, estranei compresi.

Per qualsiasi cosa appartenga a una persona in particolare, la versione che Supabase pubblica mette i file di ciascuna persona in una cartella con il suo nome:

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) divide il percorso di un file salvato nelle sue cartelle, quindi [1] è la prima. auth.jwt()->>'sub' è l'id di chi ha fatto accesso e sta facendo la richiesta. Lette insieme, le due righe dicono che puoi mettere un file nella cartella con il tuo nome, in quel bucket, e da nessun'altra parte.

Sono entrambi esempi di Supabase e non nostri, letti l'11 ottobre 2026, con my_bucket_id lasciato dove l'hanno lasciato loro, così vedi quale parte è il nome del tuo bucket.

Se preferisci vedere il risultato da fuori, la nostra scansione gratuita chiede al tuo progetto in produzione quali dei tuoi bucket consegneranno il contenuto a un estraneo. Ci mette una ventina di secondi e non serve nessun account: scansiona la tua app.

Cosa consegna una regola di lettura senza che nessuno glielo chieda

Elencare un bucket e scaricarne un file sono lo stesso privilegio, quindi una regola scritta per far funzionare i tuoi download rende anche elencabile il contenuto del bucket.

La pagina di Supabase sulle funzioni di supporto lo dice direttamente: un solo privilegio SQL come SELECT è usato da più azioni di Storage. La pagina sul controllo degli accessi avverte poi del caso specifico, sotto un esempio che apre a tutti un bucket di avatar:

Il filtro allow_any_operation() qui è determinante, perché senza di esso gli utenti potrebbero elencare il contenuto del bucket.

È la falla che misuriamo da fuori. Abbiamo scansionato 8.435 app in produzione che nominano un progetto Supabase. Il controllo dei bucket ha ottenuto una risposta su 4.703 di queste, e 792 di quelle hanno risposto alla nostra richiesta di elenco con i nomi di quello che avevano dentro, senza nessuno collegato. È circa una su sei delle app a cui abbiamo potuto chiedere.

Spesso basta un nome, perché un bucket che elenca risparmia a un estraneo la fatica di indovinare i nomi dei file. invoice-2026-03-hannah.pdf dice di chi è il file prima che qualcuno lo apra.

La correzione che Supabase documenta è dire per quale azione di Storage vale la regola:

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 e la sorella storage.allow_any_operation sono il modo in cui una regola select si restringe a una delle azioni che si dividono il privilegio. Senza una delle due, una regola che hai scritto perché la tua app potesse mostrare un'immagine è anche una regola che leggerà ad alta voce tutto quello che c'è nel bucket.

Se un bucket elencabile sia un problema per la tua app dipende da cosa contiene, ed è una domanda a cui il risultato della scansione non può rispondere al posto tuo.

Quando pubblico è la risposta giusta

Quando i file sono fatti per essere visti da chiunque li chieda, che è una categoria reale e di cui Supabase dà i propri esempi.

I casi d'uso che Supabase cita per un bucket pubblico sono foto profilo, media pubblici e contenuti di articoli di blog. Sono file che la tua app mostra a un visitatore che non ha fatto accesso, e servirli da un bucket pubblico è anche più veloce, perché i due tipi di bucket vengono messi in cache in modo diverso.

Per l'altro tipo, la documentazione nomina due modi di tirare fuori un file da un bucket privato: un download che porta il token della persona collegata, o un link firmato valido per un tempo limitato. Entrambi lasciano la decisione alle tue regole invece che a chi ha trovato l'indirizzo.

Come tenere il bucket a posto dopo oggi

Con le regole corrette si muovono ancora due cose: qualcuno gira l'interruttore mentre insegue un bug che non c'entra, e un file sparisce.

Reeve Monitor rifà per te i nove controlli dall'esterno:

• tutti e nove i controlli ogni ora, su un massimo di tre app, compreso quello sull'elenco dei bucket
• se l'app risponde, ogni 60 secondi
• un messaggio quando un risultato cambia, così un bucket che si è aperto stanotte non aspetta che tu guardi
• un rapporto mensile di quello che ha visto

Reeve Care tiene una copia di quello che c'è dentro:

• una copia cifrata del tuo database Supabase ogni notte, messa dove il tuo progetto non arriva
• ogni copia verificata prima di contare, contando le righe di ogni tabella
• anche i tuoi file caricati, appena colleghi un accesso Storage
• un ripristino con un clic quando ti serve
• tutto quello che fa Monitor

Entrambi sono sulla pagina dei prezzi, che a volte sta sotto la cifra di listino qui e mai sopra.

Cosa fare oggi

Comincia dal bucket da cui è venuto l'errore, poi guarda gli altri bucket dello stesso progetto, perché una regola scritta larga una volta di solito è stata incollata due. La checklist di sicurezza in 10 minuti copre cos'altro resta di solito aperto in un'app appena lanciata, e la guida alla sicurezza di Supabase passa in rassegna il resto di quello che un estraneo può raggiungere.