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

> Clau pública de Supabase, secret de servidor, variables d'Expo: distingeix què pot anar dins la teva app d'iPhone i prova els accessos amb dos comptes.

Pàgina original: [Clau API secreta en una app Expo: què has de protegir](https://devoria.fr/ca/blog/clau-api-secreta-app-expo)
Autor: [Mehdi Azizi](https://devoria.fr/ca/mehdi-azizi)
Publicació: 2026-09-29
Darrera revisió del contingut: 2026-10-09


## 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](https://docs.expo.dev/guides/environment-variables/).

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](https://supabase.com/docs/guides/getting-started/api-keys).

## 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](https://supabase.com/docs/guides/database/postgres/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](https://devoria.fr/ca/resources) 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](https://devoria.fr/ca/blog/guideline-5-1-2-ia-tercers-att-compartir-dades), 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](https://devoria.fr/ca/blog/crear-app-claude-code-tutorial-iphone) 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](https://devoria.fr/ca/expertise/crear-una-aplicacio-iphone) situa aquest pas dins el projecte complet. Per avançar en ordre, l'[iOS Kit](https://devoria.fr/ca/kits/ios) 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](https://devoria.fr/ca/diagnostic) 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.


## El teu projecte

[iOS Kit](https://devoria.fr/ca/kits/ios): Crea la teva app d'iPhone amb Claude Code: el codi de partida de les meves apps, les skills que revisen la seva feina, i els kits Apple Review, App Store Screenshots i ASO. 129,99 €.