Reeve Basi della sicurezza
Le nuove chiavi API di Supabase: quale va nella tua app?
Supabase ha sostituito anon e service_role con chiavi pubblicabili e segrete. Quale sta bene nella tua app, e quale non deve starci mai?
In breve
- Supabase ora emette chiavi sb_publishable_ e sb_secret_. Sostituiscono anon e service_role e fanno esattamente gli stessi due lavori.
- La chiave pubblicabile sta bene nella tua app. Quella segreta mai, e ora le distingui leggendo i primi caratteri.
- Le tue vecchie chiavi funzionano ancora oggi. Supabase ha detto che tutti i progetti dovranno abbandonarle a fine 2026.
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 chiaveanon. - Le chiavi segrete,
sb_secret_…, sostituiscono la chiaveservice_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é.
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.
Come capire quale hai
Leggi i primi caratteri. Ormai è tutto qui il controllo.
| Cosa vedi | Che cos'è | Sicura nel browser? |
|---|---|---|
sb_publishable_… | chiave pubblicabile attuale | Al suo posto |
sb_secret_… | chiave segreta attuale | Mai |
eyJ… con anon | vecchia chiave pubblicabile | Al suo posto |
eyJ… con service_role | vecchia chiave segreta | Mai |
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:
| Quando | Cosa succede |
|---|---|
| 1 novembre 2025 | I progetti ripristinati dopo questa data non ricevono più anon e service_role. |
| Fine 2026, data non fissata | Tutti i progetti dovranno usare le chiavi nuove. |
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.
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:
- Nel pannello apri Settings → API Keys e crea le chiavi nuove. Questo le aggiunge; non rimuove le vecchie, ed entrambe le coppie funzionano insieme.
- 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.
- Sostituisci la chiave segreta ovunque venga usata su un server: edge function, webhook, job pianificati, qualsiasi cosa che non sia il browser.
- 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.
- 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
Cosa fare
- Apri Settings → API Keys e guarda quali coppie ha il tuo progetto. È un minuto e ti dice a che punto sei.
- Se trovi
sb_secret_…oservice_roleda qualche parte nel codice frontend, rigenera la chiave oggi. È l'unica voce urgente di questo elenco. - Crea le chiavi nuove e sposta la tua app quando hai mezz'ora, non per la scadenza, ma perché il prefisso rende ovvio il prossimo errore.
- Già che ci sei, guarda la Row Level Security. La chiave nuova non cambia nulla di ciò che le tue policy permettono, e attivare RLS non è la stessa cosa che essere protetti.
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.
FAQ
sb_publishable_ è la stessa cosa della chiave anon?
Fa lo stesso lavoro. Dice qual è il tuo progetto perché una richiesta sappia dove andare, non porta permessi propri ed è fatta per stare nella tua app, dove chiunque può leggerla. Ciò che protegge i tuoi dati in entrambi i casi è la Row Level Security, non la chiave.
Le mie chiavi anon e service_role funzionano ancora?
Sì, oggi. Supabase le ha tenute attive durante la migrazione e puoi avere entrambe le coppie insieme. È stato annunciato che a fine 2026 tutti i progetti dovranno passare alle nuove chiavi, senza che la data esatta sia ancora fissata.
Ho entrambe le coppie nel pannello. Quale deve usare la mia app?
Quella pubblicabile, sb_publishable_. Il cambio è di una riga: sostituisci la chiave che la tua app passa quando crea il client Supabase. Nulla cambia per le tue tabelle o le tue policy, perché la nuova chiave ha esattamente i permessi che aveva la anon.
Il nuovo formato rende la mia app più sicura da solo?
No. Rende la chiave pericolosa facile da riconoscere, e questo vale denaro in errori non commessi, ma una chiave pubblicabile legge ancora tutto ciò che le tue policy le lasciano leggere. Se la Row Level Security è spenta, la chiave nuova apre il tuo database esattamente quanto lo apriva la vecchia.