Clau API secreta en una app Expo: què has de protegir

Una variable d'entorn no és necessàriament un secret

En una aplicació Expo, una variable amb el prefix EXPO_PUBLIC_ està pensada per al codi de l'aplicació. No ha de contenir cap secret de servidor. Expo explica que aquests valors s'integren al JavaScript compilat i que els usuaris de l'aplicació els poden llegir. Per tant, moure una clau a un fitxer .env no n'hi ha prou per protegir-la. Font: variables d'entorn d'Expo.

Abans de demanar a una IA que «connecti l'API», classifica el que li passes: una adreça de servei, una clau pensada per ser pública o una clau que autoritza accions privilegiades. Aquesta classificació determina on s'ha d'executar el codi.

La taula següent és una graella de disseny, no una auditoria de la teva aplicació.

Element	On posar-lo	Comprovació a fer
Adreça pública del backend	Configuració de l'app	Apunta a l'entorn correcte.
Clau Supabase publishable, o l'antiga clau anon	App, si els permisos estan ben configurats	Les regles de dades bloquegen de veritat l'accés al compte d'un altre usuari.
Clau Supabase secret o service_role	Només al servidor	No apareix ni al bundle mòbil ni als registres accessibles des del client.
Clau secreta d'un proveïdor d'IA	Només al servidor	L'app crida el teu servidor, que controla l'usuari i els límits abans de cridar el proveïdor.

Supabase distingeix les claus pensades per als clients de les claus secretes destinades a entorns de confiança. Una clau pública identifica el projecte; no substitueix els permisos sobre les dades. Font: claus API de Supabase.

Exemple: una app fictícia de diari de lectura

Imaginem una app on la Lea i en Sami registren els seus llibres i les seves notes privades. Aquest exemple serveix per preparar les proves; no descriu resultats obtinguts en una app de Devoria.

El recorregut normal sembla correcte: la Lea inicia sessió i veu les seves notes. Però això encara no respon la pregunta important: el servidor rebutja una petició de la Lea que apunta a una nota d'en Sami?

Un filtre a la interfície, com ara «mostrar les notes de l'usuari connectat», millora la visualització. Però l'autorització també s'ha d'aplicar a les dades. A Supabase, les regles Row Level Security permeten restringir les files accessibles segons la sessió. Supabase recomana activar-les per a les taules exposades per l'API i explica les polítiques de lectura i escriptura. Font: Row Level Security.

Per al teu propi projecte de prova, associa cada nota al seu propietari i defineix per separat qui la pot llegir, crear, modificar i eliminar. Revisa també els fitxers: protegir una fila de la base de dades no demostra que una imatge sigui privada.

La prova que has de fer amb dos comptes de test

Prepara dos comptes que controlis, un llibre diferent a cadascun i una nota petita i reconeixible. Fes servir dades fictícies en un entorn de test autoritzat.

1. Llegir la seva nota. El compte A troba la nota A.
2. Llegir la nota de B des d'A. La petició no revela el seu contingut privat.
3. Modificar la nota de B des d'A. El servidor ho rebutja; la nota B queda igual.
4. Crear en nom de B des d'A. El servidor rebutja aquesta atribució.
5. Llegir sense sessió. No es retorna cap contingut privat.
6. Obrir el fitxer privat de B des d'A. El fitxer no és accessible.

Apunta el resultat real, la versió provada i l'error, si n'hi ha. «Les regles estan activades» no és un resultat de prova. La graella de proves disponible als recursos et pot servir de base per guardar aquestes evidències.

Fes passar les crides de pagament pel teu servidor

Per a una funció que resumeix un llibre amb una API d'IA, el recorregut pot ser: app → el teu servidor → proveïdor → el teu servidor → app. La clau secreta es queda al servidor. Aquesta arquitectura sola no n'hi ha prou: l'accés al servidor també s'ha de controlar.

A l'exemple fictici, el servidor ha de comprovar, entre altres coses, la sessió, que el llibre pertany a la persona, limitar les peticions repetides i retornar un error comprensible si el proveïdor no respon. El client no decideix pel seu compte que un usuari té accés de pagament.

Prepara quatre proves: usuari sense sessió, llibre d'un altre compte, límit assolit i proveïdor no disponible. L'última et permet comprovar que l'app surt de l'estat de càrrega sense perdre el que s'ha escrit.

Què pots demanar al teu assistent de codi

Aquí tens una instrucció de revisió per adaptar al teu repositori, sense enganxar-hi els teus valors secrets:

Fes la llista de les variables que fan servir el codi mòbil i el servidor, mostrant només els seus noms. Identifica les crides privilegiades presents al costat del client. Per a les dades privades, descriu els controls de lectura i escriptura i després proposa una prova amb dos comptes de test. No facis cap rotació de claus ni cap canvi a producció sense validació.

Llegeix la resposta amb el codi corresponent al davant. Un assistent pot detectar una incoherència; la seva resposta no substitueix executar les proves. La guia crear una aplicació amb Claude Code explica com dividir aquesta feina.

Abans de continuar amb la teva app

Has de poder explicar tres coses de manera senzilla: quins valors són públics, quines operacions passen pel servidor i quines proves demostren que un compte no veu les dades d'un altre. Si algun d'aquests punts no està clar, aclareix-lo abans d'afegir funcions.

La pàgina crear una aplicació d'iPhone situa aquest pas dins el projecte complet. Per avançar en ordre, l'iOS Kit proposa un recorregut en quatre etapes i un codi de partida que ja inclou els comptes i la IA. Si ja no saps per quina etapa reprendre, el diagnòstic gratuït torna a posar ordre al teu projecte i t'envia la meva checklist antirebuig d'Apple.

Preguntes freqüents

On poso una clau API secreta en una app Expo?

Al teu servidor, mai a l'app. La clau Supabase secret o service_role, igual que la clau secreta d'un proveïdor d'IA, s'ha de quedar només al servidor. L'app crida el teu servidor, que controla l'usuari i els límits abans de cridar el proveïdor. Comprova que cap d'aquestes claus aparegui al bundle mòbil ni als registres accessibles des del client.

Un fitxer .env protegeix la meva clau API a Expo?

No per si sol. Una variable amb el prefix EXPO_PUBLIC_ està pensada per al codi de l'aplicació i no ha de contenir cap secret de servidor. Expo explica que aquests valors s'integren al JavaScript compilat i que els usuaris de l'aplicació els poden llegir. Per tant, moure una clau a un fitxer .env no n'hi ha prou per protegir-la.

Quina diferència hi ha entre una clau API pública i una de secreta?

Una clau pública està pensada per anar dins l'app: identifica el projecte, però no substitueix els permisos sobre les dades. Una clau secreta autoritza accions privilegiades i queda reservada als entorns de confiança. A Supabase, la clau publishable, o l'antiga clau anon, pot quedar-se a l'app si els permisos estan ben configurats. Les claus secret i service_role es queden al servidor.

Com crido una API d'IA des d'una app Expo sense exposar la clau?

Fes passar la crida pel teu servidor: l'app crida el servidor, que crida el proveïdor i després retorna la resposta a l'app. La clau secreta es queda al servidor. El servidor també ha de comprovar la sessió, limitar les peticions repetides i retornar un error comprensible si el proveïdor no respon. El client no decideix pel seu compte que un usuari té accés de pagament.

Com comprovo que cada usuari només veu les seves pròpies dades?

Prepara dos comptes de test que controlis, amb una nota reconeixible a cadascun. Des del compte A, intenta llegir, modificar i crear en nom del compte B, i després obrir el fitxer privat de B. Fes també les proves sense sessió: cada petició s'ha de rebutjar o no ha de revelar res. Apunta el resultat real, perquè «les regles estan activades» no és un resultat de prova.

Com demano a una IA que revisi les claus de la meva app?

Demana-li que faci la llista de les variables del codi mòbil i del servidor, mostrant només els seus noms, sense enganxar els teus valors secrets. Demana-li també que identifiqui les crides privilegiades presents al costat del client i que proposi una prova amb dos comptes de test. Prohibeix qualsevol rotació de claus o canvi a producció sense validació. La seva resposta no substitueix executar les proves.