Le nuove chiavi API di Supabase: quale va nella tua app?

Se hai aperto di recente il pannello Supabase e hai trovato chiavi che iniziano con sb_publishable_ e sb_secret_ dove prima c'erano anon e service_role, non si è rotto niente. Supabase ha rinominato le sue chiavi API, e la coppia che conoscevi è in uscita.

Il cambiamento è piccolo in quello che fa e grande in quello che evita. Le due chiavi svolgono ancora esattamente i due compiti di sempre. La novità è che ora vedi quale è quale senza aprire nulla.

Cosa ha cambiato davvero Supabase

Supabase ha annunciato le nuove chiavi a luglio 2025, insieme a un cambiamento nel modo in cui firma i token di accesso. Due cose ne hanno sostituite due:

• La chiave pubblicabile, sb_publishable_…, sostituisce la chiave anon.
• Le chiavi segrete, sb_secret_…, sostituiscono la chiave service_role.

I permessi non cambiano. Una chiave pubblicabile continua a identificare il tuo progetto e non porta permessi propri; una segreta continua ad aggirare ogni regola tu abbia scritto. Se sai già quali chiavi sono sicure in un frontend, niente di quell'intuizione è diventato falso.

Due differenze pratiche vale la pena conoscerle. Puoi avere più chiavi segrete insieme e revocarle una alla volta: ruotare una chiave non significa più un momento in cui tutto ciò che la usava è rotto. E le vecchie chiavi avevano una proprietà che quasi nessuno notava: erano JWT che scadono dieci anni dopo la creazione del progetto. Le nuove non portano una scadenza dentro di sé.

La chiave anon è la stessa cosa della chiave pubblicabile?

Sì in quello che fa, no in quello che è.

sb_publishable_… fa esattamente il lavoro della chiave anon: nomina il tuo progetto perché una richiesta sappia dove andare, non porta permessi propri, ed è pensata per stare nella tua app dove chiunque può leggerla. Tutto quello che avevi già capito della chiave anon resta vero. Se scambi l'una con l'altra, nessuna tabella diventa più o meno leggibile, perché nessuna delle due ha mai protetto le tue righe. È la Row Level Security a farlo.

Quello che cambia è il valore in sé. Sono stringhe diverse in formati diversi, emesse separatamente, e un progetto può tenere entrambe le coppie insieme durante la migrazione. Quindi «la stessa chiave con un nome nuovo» è l'immagine sbagliata. È una chiave nuova che fa un lavoro vecchio, e la tua app deve essere avvertita.

Una conseguenza coglie in contropiede: abilitare le chiavi nuove non sposta la tua app. Supabase le emette e lascia la tua app girare con quello che le hai dato. Il passaggio è una modifica di una riga che fai tu, nel punto in cui la tua app crea il suo client Supabase.

Quale delle due sta bene nella tua app

Quella pubblicabile, e soltanto quella.

La tua app gira nel browser del tuo visitatore, e la richiesta al tuo database parte da lì. Deve dire a quale progetto appartiene, e quell'identificativo arriva a ogni visitatore per progetto. sb_publishable_… è la chiave costruita per questo: trovarla nella tua app non è un problema, e non lo è mai stato.

sb_secret_… è l'opposto. Legge e scrive ogni riga di ogni tabella da qualunque posto, ignorando del tutto le tue policy, ed è esattamente il suo scopo. Il suo posto è un server, una edge function, un worker: nessun luogo che un browser possa raggiungere. Se una è mai finita incollata nel codice frontend, rigenerala nel pannello prima di toccare altro, perché cancellare la riga non chiude la porta.

Che aspetto ha una chiave sb_publishable_?

Una sola stringa continua che inizia con il letterale sb_publishable_, seguito da una parte centrale casuale. Nessun punto al suo interno, e niente là dentro che tu possa decodificare. La sua controparte segreta si legge allo stesso modo, con sb_secret_ davanti.

La coppia vecchia non le somiglia per niente. anon e service_role sono JWT: tre blocchi separati da punti, lunghi qualche centinaio di caratteri, che cominciano con eyJ. Il blocco centrale non è cifrato, solo codificato, quindi chiunque può incollarlo in un decodificatore e leggere il campo role dentro. È così che si distinguevano le due prima, ed è il motivo per cui in tanti non l'hanno mai fatto.

Leggere i primi quindici caratteri è tutta la verifica oggi. La chiave pericolosa si annuncia nella parte della stringa su cui l'occhio cade per primo, invece che in mezzo a qualcosa che devi aprire.

Come capire quale hai

Leggi i primi caratteri. Ormai è tutto qui il controllo.

Una chiave attuale è una stringa lunga in due metà: un centro casuale e un breve codice di controllo alla fine. Una vecchia chiave è fatta di tre blocchi separati da punti, e quello centrale è testo leggibile invece che cifratura, ed ecco perché distinguere la vecchia coppia voleva dire decodificarla e leggere il campo role.

Se trovi una chiave nella tua app e non capisci quale sia, la nostra scansione gratuita legge il tuo sito dal vivo dall'esterno e dice cosa riesce a vedere. Ci vogliono una ventina di secondi e non serve un account: scansiona la tua app.

Le mie vecchie chiavi anon e service_role funzionano ancora?

Oggi sì. Supabase ha pubblicato un calendario, non un interruttore:

Quindi non c'è un'emergenza questa settimana, e c'è una scadenza quest'anno. Se la tua app è stata costruita prima della rinomina e da allora non è stata toccata, in questo momento gira su chiavi vecchie e continuerà ancora per un po'.

L'argomento per muoversi presto non è la scadenza. È il giorno in cui qualcuno incolla la chiave sbagliata in un prompt: sb_secret_ si annuncia, eyJ… no.

Che cosa sono le chiavi API legacy di Supabase?

Legacy è il nome che Supabase dà oggi alla coppia originale, anon e service_role, insieme al segreto JWT che le firma. Ogni progetto creato prima di metà 2025 è partito con quelle, cioè la maggior parte delle app vibe-coded.

Differiscono dalla coppia nuova in modi che vale la pena conoscere. Essendo JWT, portano una scadenza dieci anni dopo la creazione del progetto, dentro la chiave stessa, dove nessuno guarda. Non si possono ruotare per niente: Supabase ha detto che ruotare i segreti legacy anon, service_role e JWT non è più possibile, quindi invalidarne una trapelata significa passare alle chiavi nuove e disattivare la coppia vecchia. E un progetto ripristinato dopo il 1 novembre 2025 non le riceve proprio.

Se una delle tue è già trapelata, quella migrazione è l'unico modo per invalidarla, e l'ordine in cui farla dipende dal fatto che la chiave sia già in un bundle che i tuoi visitatori scaricano.

Come cambiare senza rompere la tua app

La guida alla migrazione di Supabase è il riferimento. La versione breve, per un'app che non hai scritto a mano, dando per scontato che tu sappia già trovare la pagina dove stanno le tue chiavi:

1. Nel pannello apri Settings → API Keys e crea le chiavi nuove. Questo le aggiunge; non rimuove le vecchie, ed entrambe le coppie funzionano insieme.
2. Trova il punto in cui la tua app crea il client Supabase e sostituisci la chiave pubblicabile. In un builder come Lovable o Bolt di solito è un valore nelle impostazioni del progetto, non una riga di codice.
3. Sostituisci la chiave segreta ovunque venga usata su un server: edge function, webhook, job pianificati, qualsiasi cosa che non sia il browser.
4. Carica la tua app e passa dalle parti che leggono e scrivono dati. Una chiave pubblicabile sbagliata fallisce subito e in modo rumoroso, che è il caso buono.
5. Solo quando tutto funziona, disattiva le chiavi vecchie.

Il passo 5 è quello da lasciare per ultimo, e conviene farlo di proposito piuttosto che mai: i progetti migrati a metà, in cui l'app porta ancora una vecchia chiave anon accanto a una sb_publishable_ viva, sono comuni e confondono quando qualcosa non va.

Cosa fare questa settimana

Se vuoi la versione specifica per piattaforma di cosa controllare, abbiamo una guida in linguaggio semplice per le app con Supabase, e la checklist di sicurezza in 10 minuti copre questo punto insieme alle altre cose da disattivare in un'app appena lanciata.