# Chiave API segreta in un'app Expo: cosa proteggere

> Chiave pubblica Supabase, segreto server, variabili Expo: capisci cosa può finire nella tua app iPhone e testa gli accessi con due account.

Pagina originale: [Chiave API segreta in un'app Expo: cosa proteggere](https://devoria.fr/it/blog/chiave-api-segreta-app-expo)
Autore: [Mehdi Azizi](https://devoria.fr/it/mehdi-azizi)
Pubblicazione: 2026-09-29
Ultima revisione dei contenuti: 2026-10-09


## Una variabile d'ambiente non è per forza un segreto

In un'app Expo, una variabile con il prefisso `EXPO_PUBLIC_` è destinata al codice dell'app. Non deve contenere un segreto server. Expo spiega che questi valori vengono inclusi nel JavaScript compilato e possono essere letti dagli utenti dell'app. Spostare una chiave in un file `.env` quindi non basta a proteggerla. [Fonte: variabili d'ambiente Expo](https://docs.expo.dev/guides/environment-variables/).

Prima di chiedere a un'IA di "collegare l'API", classifica quello che le affidi: un indirizzo di servizio, una chiave pensata per essere pubblica, oppure una chiave che autorizza azioni privilegiate. Questa classificazione decide dove deve girare il codice.

La tabella seguente è una griglia di progettazione, non un audit della tua app.

| Elemento                                           | Dove metterlo                                        | Verifica da fare                                                                              |
| -------------------------------------------------- | ---------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| Indirizzo pubblico del backend                     | Configurazione dell'app                              | Punta all'ambiente giusto.                                                                    |
| Chiave Supabase publishable, o vecchia chiave anon | Nell'app, se le autorizzazioni sono configurate bene | Le regole sui dati bloccano davvero l'accesso all'account di un altro utente.                 |
| Chiave Supabase secret o service_role              | Solo sul server                                      | Non compare né nel bundle mobile né nei log accessibili al client.                            |
| Chiave segreta di un fornitore di IA               | Solo sul server                                      | L'app chiama il tuo server, che controlla l'utente e i limiti prima di chiamare il fornitore. |

Supabase distingue le chiavi pensate per i client dalle chiavi segrete destinate agli ambienti fidati. Una chiave pubblica identifica il progetto: non sostituisce i permessi sui dati. [Fonte: chiavi API Supabase](https://supabase.com/docs/guides/getting-started/api-keys).

## Esempio: un'app fittizia di diario di lettura

Immaginiamo un'app in cui Léa e Sami salvano i loro libri e le loro note private. L'esempio serve a preparare i test: non descrive risultati ottenuti su un'app Devoria.

Il percorso normale sembra corretto: Léa fa login e vede le sue note. Ma questo non risponde ancora alla domanda importante: il server rifiuta una richiesta di Léa che punta a una nota di Sami?

Un filtro nell'interfaccia, tipo "mostra le note dell'utente connesso", migliora la visualizzazione. Ma l'autorizzazione va applicata anche lato dati. In Supabase, le regole Row Level Security permettono di limitare le righe accessibili in base alla sessione. Supabase consiglia di attivarle per le tabelle esposte dall'API e spiega le policy di lettura e scrittura. [Fonte: Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security).

Per il tuo progetto di test, associa ogni nota al suo proprietario e definisci separatamente chi può leggerla, crearla, modificarla ed eliminarla. Controlla anche i file: proteggere una riga del database non dimostra che un'immagine sia privata.

## Il collaudo da fare con due account di test

Prepara due account che controlli tu, un libro diverso in ciascuno e una piccola nota riconoscibile. Usa dati fittizi in un ambiente di test autorizzato.

1. **Leggere la propria nota.** L'account A ritrova la nota A.
2. **Leggere la nota di B da A.** La richiesta non rivela il contenuto privato.
3. **Modificare la nota di B da A.** Il server rifiuta; la nota B resta invariata.
4. **Creare a nome di B da A.** Il server rifiuta questa attribuzione.
5. **Leggere senza sessione.** Non viene restituito nessun contenuto privato.
6. **Aprire il file privato di B da A.** Il file non è accessibile.

Annota il risultato reale, la versione testata e l'eventuale errore. "Le regole sono attive" non è un risultato di test. La [griglia di collaudo disponibile nelle risorse](https://devoria.fr/it/resources) può farti da base per conservare queste prove.

## Far passare una chiamata a pagamento dal tuo server

Per una funzione che riassume un libro con [un'API di IA](https://devoria.fr/it/blog/guideline-5-1-2-ia-terze-parti-att-condivisione-dati), il percorso può essere: app → il tuo server → fornitore → il tuo server → app. La chiave segreta resta sul server. Questa architettura da sola non basta: anche l'accesso al server va controllato.

Nell'esempio fittizio, il server deve in particolare verificare la sessione, verificare che il libro appartenga alla persona, limitare le richieste ripetute e restituire un errore comprensibile se il fornitore non risponde. Non è il client a decidere da solo che un utente ha diritto a un accesso a pagamento.

Prepara quattro prove: utente non connesso, libro di un altro account, limite raggiunto e fornitore non disponibile. L'ultima ti permette di verificare che l'app esca dallo stato di caricamento senza perdere quello che l'utente ha scritto.

## Cosa puoi chiedere al tuo assistente di programmazione

Ecco un'istruzione di revisione da adattare al tuo repository, senza incollarci i tuoi valori segreti:

> Elenca le variabili usate dal codice mobile e dal server, mostrando solo i loro nomi. Individua le chiamate privilegiate presenti lato client. Per i dati privati, descrivi i controlli di lettura e scrittura, poi proponi un collaudo con due account di test. Non fare nessuna rotazione di chiavi né modifiche in produzione senza approvazione.

Leggi la risposta insieme al codice corrispondente. Un assistente può individuare un'incoerenza; la sua risposta non sostituisce l'esecuzione dei test. La guida [creare un'app con Claude Code](https://devoria.fr/it/blog/creare-app-claude-code-tutorial-iphone) spiega come suddividere questo lavoro.

## Prima di andare avanti con la tua app

Devi saper spiegare tre cose in modo semplice: quali valori sono pubblici, quali operazioni passano dal server e quali test dimostrano che un account non vede i dati di un altro. Se uno di questi punti non è chiaro, chiariscilo prima di aggiungere funzioni.

La pagina [creare un'app per iPhone](https://devoria.fr/it/expertise/creare-app-iphone) colloca questa fase nel progetto completo. Per procedere con ordine, l'[iOS Kit](https://devoria.fr/it/kits/ios) propone un percorso in quattro fasi e uno Starter Code che include già account e IA. Se non sai più da quale fase ripartire, la [diagnosi gratuita](https://devoria.fr/it/diagnostic) rimette in ordine il tuo progetto e ti invia la mia checklist anti-rifiuto di Apple.

## Domande frequenti

### Dove mettere una chiave API segreta in un'app Expo?

Sul tuo server, mai nell'app. La chiave Supabase secret o service_role, come la chiave segreta di un fornitore di IA, deve restare solo lato server. L'app chiama il tuo server, che controlla l'utente e i limiti prima di chiamare il fornitore. Verifica che nessuna di queste chiavi compaia nel bundle mobile o nei log accessibili al client.

### Un file .env protegge la mia chiave API in Expo?

Non da solo. Una variabile con il prefisso `EXPO_PUBLIC_` è destinata al codice dell'app e non deve contenere un segreto server. Expo spiega che questi valori vengono inclusi nel JavaScript compilato e possono essere letti dagli utenti dell'app. Spostare una chiave in un file `.env` quindi non basta a proteggerla.

### Che differenza c'è tra una chiave API pubblica e una segreta?

Una chiave pubblica è pensata per essere distribuita nell'app: identifica il progetto, ma non sostituisce i permessi sui dati. Una chiave segreta autorizza azioni privilegiate ed è riservata agli ambienti fidati. In Supabase, la chiave publishable, o la vecchia chiave anon, può stare nell'app se le autorizzazioni sono configurate bene. Le chiavi secret e service_role restano sul server.

### Come chiamare un'API di IA da un'app Expo senza esporre la chiave?

Fai passare la chiamata dal tuo server: l'app chiama il server, che chiama il fornitore e poi restituisce la risposta all'app. La chiave segreta resta sul server. Il server deve anche verificare la sessione, limitare le richieste ripetute e restituire un errore comprensibile se il fornitore non risponde. Non è il client a decidere da solo che un utente ha diritto a un accesso a pagamento.

### Come verificare che ogni utente veda solo i propri dati?

Prepara due account di test che controlli tu, con una nota riconoscibile in ciascuno. Dall'account A, prova a leggere, modificare e creare a nome dell'account B, poi ad aprire il file privato di B. Fai anche le prove senza sessione: ogni richiesta deve essere rifiutata o non rivelare nulla. Annota il risultato reale, perché "le regole sono attive" non è un risultato di test.

### Come chiedere a un'IA di controllare le chiavi della mia app?

Chiedile di elencare le variabili del codice mobile e del server, mostrando solo i loro nomi, senza incollare i tuoi valori segreti. Chiedile anche di individuare le chiamate privilegiate presenti lato client e di proporre un collaudo con due account di test. Vieta qualsiasi rotazione di chiavi o modifica in produzione senza approvazione. La sua risposta non sostituisce l'esecuzione dei test.


## Il tuo progetto

[iOS Kit](https://devoria.fr/it/kits/ios): Crea la tua app iPhone con Claude Code: lo Starter Code delle mie app, gli skill che verificano il suo lavoro, e l'Apple Review Kit, l'App Store Screenshots Kit e l'ASO Kit. 129,99 €.