Dove trovare le chiavi API di Supabase: anon, service_role e URL

Qualcosa ti ha chiesto la tua chiave Supabase. Una guida di installazione, un thread di supporto, o una IA a cui hai detto di andare a sistemare la tua app. Apri la dashboard, trovi una pagina con un indirizzo e due o tre chiavi con nomi tipo anon e service_role, e ognuna sembra poter essere la risposta.

Oppure è l'altra versione della scena. Qualcuno ha aperto il tuo sito, ha premuto F12 e ti ha detto che una chiave è esposta. Adesso vuoi guardare la chiave che ha trovato, e non sai dove abiti.

Quasi tutte le guide partono dalla pagina delle chiavi API. Il che dà per scontato che tu sappia già quale progetto Supabase è il tuo, ed è esattamente il passaggio che un builder ha fatto al posto tuo senza mai spiegarlo.

Dove sono le chiavi API di Supabase?

Nella dashboard, dentro il tuo progetto, sotto Settings → API Keys.

Il percorso completo: entra su supabase.com, scegli il tuo progetto dalla lista, apri Settings nella barra laterale a sinistra, poi API Keys. Quasi tutte le guide e gli screenshot che troverai chiamano quella pagina Settings → API, perché fino a poco fa si chiamava così. È la stessa pagina con gli stessi valori.

Tutto quello che c'è sopra è una di due cose. Un indirizzo, che dice dove vive il tuo progetto. Oppure una chiave, che decide cosa una richiesta può fare una volta arrivata. La pagina li elenca insieme, in una sola colonna, con lo stesso carattere.

Non ho mai configurato Supabase. Qual è il mio progetto?

Leggi l'indirizzo che la tua app sta già usando. La risposta è lì dentro.

Ogni progetto Supabase ha un riferimento: una stringa corta e casuale che è anche la prima parte dell'indirizzo del progetto, https://yourreference.supabase.co. La tua app manda una richiesta a quell'indirizzo a ogni caricamento di pagina, quindi la stringa è già dentro la tua app, ed è la stessa con cui la dashboard identifica il tuo progetto.

Tre posti dove trovarla senza chiedere a nessuno:

• Nel tuo builder. Lovable, Bolt, v0 e gli altri mostrano il progetto Supabase collegato da qualche parte nelle impostazioni o nel pannello delle integrazioni del tuo progetto.
• Nel tuo browser. Apri la tua app in produzione, premi F12, vai sulla scheda Network e ricarica la pagina. Le richieste che partono verso qualcosa con .supabase.co portano il riferimento nel proprio indirizzo.
• Nel sorgente della pagina, se la tua app scrive l'indirizzo nell'HTML invece che in un file di script.

Poi entra su supabase.com e confronta quel riferimento con la lista dei tuoi progetti. I builder collegano Supabase attraverso il tuo stesso account, quindi il progetto di solito sta in una dashboard a cui ti sei iscritto una volta e che non hai mai usato. Una volta dentro un progetto il riferimento compare nella barra degli indirizzi del browser, ed è così che confermi di essere in quello giusto prima di copiarne qualcosa.

Le quattro cose su quella pagina

Un indirizzo e tre chiavi. Due vanno nella tua app e due non lasciano mai la dashboard.

C'è una scorciatoia sulla pagina stessa. Supabase stampa l'URL del progetto e la chiave pubblicabile dove puoi leggerle, e copre la chiave segreta e il valore JWT con dei puntini finché non chiedi di vederli. Le due che copre sono esattamente le due che nella tua app non ci vanno mai.

Dov'è l'URL del mio progetto Supabase?

In due posti, e probabilmente ne stai già guardando uno. La dashboard lo stampa in cima a Settings → API Keys, con l'etichetta Project URL. La barra degli indirizzi del browser mostra la stessa stringa ogni volta che la tua app parla con Supabase, nella forma https://yourreference.supabase.co.

Nel codice porta uno di tre nomi, e tutti e tre contengono quella stessa stringa:

• VITE_SUPABASE_URL in un'app costruita con Vite, che copre gran parte di quello che producono Lovable e Bolt
• NEXT_PUBLIC_SUPABASE_URL in un'app Next.js
• SUPABASE_URL su un server, in una edge function o in uno script

La parte centrale, yourreference, è il riferimento del tuo progetto. È la stringa con cui la dashboard riconosce il progetto, e quella da confrontare quando hai più progetti e nessuna idea di quale appartenga a questa app.

È un indirizzo più che un segreto, ed è per questo che sta in chiaro accanto alla chiave pubblicabile.

Dov'è la chiave service_role, e che cos'è SUPABASE_SERVICE_ROLE_KEY?

Sulla stessa pagina di tutto il resto. Apri Settings → API Keys e cerca la riga service_role, o secret su un progetto creato di recente. A differenza dell'URL e della chiave pubblicabile, il suo valore resta dietro un comando di rivelazione finché non lo chiedi.

Quel comando è l'unico indizio che la dashboard ti dà del fatto che questa è diversa, e merita di essere preso sul serio: Supabase copre esattamente i valori che non devono mai arrivare a un browser.

SUPABASE_SERVICE_ROLE_KEY è un nome di variabile più che una seconda chiave: dietro c'è il valore che hai appena rivelato. Lo incontrerai in un file .env, nelle impostazioni d'ambiente del tuo host, o nei secret di una edge function. Quello che conta è il prefisso davanti. Una variabile chiamata VITE_SUPABASE_SERVICE_ROLE_KEY o NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY viene compilata dentro il JavaScript che i tuoi visitatori scaricano, quindi la chiave è pubblica nel momento in cui pubblichi. Quei prefissi sono istruzioni a pubblicare, non sviste.

Il posto giusto è una edge function, un gestore di webhook, un job pianificato o uno script di migrazione: ovunque il codice giri su una macchina che controlli e nessun visitatore possa aprire il file. Questa è la chiave che ignora del tutto la Row Level Security, quindi legge ogni riga di ogni tabella qualunque cosa dicano le tue regole.

Se non sei sicuro che la tua sia rimasta sul server, il nostro scanner di sicurezza per siti gratuito legge il tuo sito online dall'esterno e nomina le chiavi che trova, in una ventina di secondi.

Di quale chiave ha bisogno la mia app?

L'URL del progetto e la chiave pubblicabile. Nient'altro, mai.

La tua app gira nel browser dei tuoi visitatori e parla con Supabase da lì, quindi entrambi quei valori viaggiano verso ogni visitatore per costruzione. Non è una fuga di dati e non lo è mai stata. Quello che impedisce a uno sconosciuto di leggere tutto il tuo database con una chiave pubblicabile è la Row Level Security: le regole che decidono, riga per riga, chi può vedere cosa.

Quelle regole sono quindi la cosa da controllare quando ti preoccupi, e accenderle non è la stessa cosa che essere protetti. La versione lunga del perché una chiave è sicura in pubblico sta in quali chiavi API sono sicure nel frontend.

Come faccio a sapere quale chiave ha davvero portato la mia app?

Dalla dashboard non lo capisci. Elenca le chiavi che il tuo progetto ha, non quella che è finita dentro la tua app.

Sono due domande diverse, e solo la seconda può farti male. Un progetto può avere una pagina di impostazioni del tutto normale e avere comunque la sua chiave segreta incollata in un file che chiunque può aprire. Per rispondere devi leggere la chiave che sta davvero nell'app.

In un progetto nuovo, leggi i primi caratteri. sb_publishable_ è quella che ci deve stare. sb_secret_ è quella di cui occuparsi oggi.

In un progetto vecchio, devi guardare dentro la chiave. anon e service_role sono JWT: tre blocchi separati da punti, e quello centrale si decodifica in testo perfettamente leggibile. Porta un campo role, e quella sola parola è tutta la differenza fra le due. Come leggerlo.

Se preferisci non passare la tua app a mano, la nostra scansione gratuita legge il tuo sito in produzione dall'esterno e nomina le chiavi che riesce a vedere, insieme al fatto che le tue tabelle rispondano o no a uno sconosciuto che chiede. Ci vogliono circa 20 secondi e non serve un account: scansiona la tua app.

E se la chiave segreta è già nella mia app?

Occupati della chiave prima di toccare qualsiasi codice, e su Supabase potrebbe non voler dire quello che ti aspetti.

Il consiglio abituale è ruotare: generi una chiave nuova, revochi quella vecchia, e il valore trapelato smette di funzionare. Per le chiavi nuove vale ancora. Un progetto può tenere più chiavi sb_secret_ insieme e revocarle una alla volta, quindi sostituirne una non significa più un minuto in cui tutto ciò che la usava è rotto.

Per la coppia originale non vale per niente. Le note di risoluzione dei problemi di Supabase dicono che non è più possibile ruotare i vecchi segreti anon, service_role e JWT. Rendere inutilizzabile una vecchia chiave service_role trapelata passa dal creare le chiavi nuove, spostare app e codice server su di esse, e poi disattivare la vecchia coppia. Cosa comporta quella migrazione sono una manciata di passaggi nella dashboard e un valore sostituito nella tua app, cosa parecchio più facile in un pomeriggio tranquillo che nel giorno in cui ti serve.

Cosa fare adesso

Se preferisci affrontarlo come una lista, la checklist di sicurezza in 10 minuti copre questo e le altre cose da spegnere in una app appena lanciata, e abbiamo una guida in linguaggio semplice per le app Supabase.