Clave API secreta en Expo: qué proteger en tu app

Una variable de entorno no es necesariamente un secreto

En una aplicación Expo, una variable con el prefijo EXPO_PUBLIC_ está pensada para el código de la app. No debe contener un secreto de servidor. Expo explica que estos valores se integran en el JavaScript compilado y los usuarios de la aplicación pueden leerlos. Así que mover una clave a un archivo .env no basta para protegerla. Fuente: variables de entorno de Expo.

Antes de pedirle a una IA que «conecte la API», clasifica lo que le entregas: una dirección de servicio, una clave pensada para ser pública o una clave que autoriza acciones privilegiadas. Esa clasificación determina dónde debe ejecutarse el código.

La siguiente tabla es una guía de diseño, no una auditoría de tu aplicación.

Elemento	Dónde colocarlo	Verificación que hacer
Dirección pública del backend	Configuración de la app	Apunta al entorno correcto.
Clave publishable de Supabase, o antigua clave anon	En la app si los permisos están bien configurados	Las reglas de datos bloquean de verdad el acceso a la cuenta de otro usuario.
Clave secret o service_role de Supabase	Solo en el servidor	No aparece ni en el bundle móvil ni en los registros accesibles para el cliente.
Clave secreta de un proveedor de IA	Solo en el servidor	La app llama a tu servidor, que controla al usuario y los límites antes de llamar al proveedor.

Supabase distingue las claves pensadas para los clientes de las claves secretas destinadas a entornos de confianza. Una clave pública identifica el proyecto; no sustituye los permisos sobre los datos. Fuente: claves API de Supabase.

Ejemplo: una app ficticia de diario de lectura

Imaginemos una app en la que Léa y Sami registran sus libros y sus notas privadas. Este ejemplo sirve para preparar las pruebas; no describe resultados obtenidos en una app de Devoria.

El recorrido normal parece correcto: Léa inicia sesión y ve sus notas. Pero eso todavía no responde la pregunta importante: ¿el servidor rechaza una solicitud de Léa dirigida a una nota de Sami?

Un filtro en la interfaz, como «mostrar las notas del usuario conectado», mejora lo que se ve en pantalla. La autorización también tiene que aplicarse del lado de los datos. En Supabase, las reglas de Row Level Security permiten restringir las filas accesibles según la sesión. Supabase recomienda activarlas en las tablas expuestas por la API y explica las políticas de lectura y escritura. Fuente: Row Level Security.

En tu propio proyecto de prueba, asocia cada nota a su propietario y define por separado quién puede leerla, crearla, modificarla y eliminarla. Revisa también los archivos: proteger una fila de la base de datos no demuestra que una imagen sea privada.

La prueba que hay que hacer con dos cuentas de prueba

Prepara dos cuentas que controles, un libro distinto en cada una y una nota corta fácil de reconocer. Usa datos ficticios en un entorno de prueba autorizado.

1. Leer su propia nota. La cuenta A encuentra la nota A.
2. Leer la nota de B desde A. La solicitud no revela su contenido privado.
3. Modificar la nota de B desde A. El servidor la rechaza; la nota B queda igual.
4. Crear en nombre de B desde A. El servidor rechaza esa asignación.
5. Leer sin sesión. No se devuelve ningún contenido privado.
6. Abrir el archivo privado de B desde A. El archivo no es accesible.

Anota el resultado real, la versión probada y el error, si lo hay. «Las reglas están activadas» no es un resultado de prueba. La plantilla de pruebas disponible en los recursos puede servirte de base para guardar estas evidencias.

Pasar las llamadas de pago por tu servidor

Para una función que resume un libro con una API de IA, el recorrido puede ser: app → tu servidor → proveedor → tu servidor → app. La clave secreta se queda en el servidor. Esta arquitectura no basta por sí sola: el acceso al servidor también tiene que estar controlado.

En el ejemplo ficticio, el servidor debe, entre otras cosas, verificar la sesión, comprobar que el libro pertenece a esa persona, limitar las solicitudes repetidas y devolver un error comprensible si el proveedor no responde. El cliente no decide por sí mismo que un usuario tiene acceso de pago.

Prepara cuatro pruebas: usuario sin sesión, libro de otra cuenta, límite alcanzado y proveedor no disponible. La última permite comprobar que la app sale del estado de carga sin perder lo que el usuario escribió.

Lo que puedes pedirle a tu asistente de código

Aquí tienes una instrucción de revisión para adaptar a tu repositorio, sin pegar tus valores secretos:

Haz un inventario de las variables que usan el código móvil y el servidor, mostrando solo sus nombres. Identifica las llamadas privilegiadas presentes del lado del cliente. Para los datos privados, describe los controles de lectura y escritura, y luego propone una prueba con dos cuentas de prueba. No hagas ninguna rotación de claves ni cambios en producción sin validación.

Lee la respuesta junto con el código correspondiente. Un asistente puede detectar una incoherencia; su respuesta no sustituye la ejecución de las pruebas. La guía crear una aplicación con Claude Code explica cómo dividir este trabajo.

Antes de seguir con tu aplicación

Tienes que poder explicar tres cosas de forma sencilla: qué valores son públicos, qué operaciones pasan por el servidor y qué pruebas demuestran que una cuenta no ve los datos de otra. Si alguno de estos puntos sigue sin estar claro, acláralo antes de añadir funciones.

La página crear una aplicación para iPhone sitúa esta etapa dentro del proyecto completo. Para avanzar en orden, el iOS Kit ofrece un recorrido en cuatro etapas y un código de partida que ya incluye las cuentas y la IA. Si ya no sabes por qué etapa retomar, el diagnóstico gratuito pone tu proyecto en orden y te envía mi checklist para evitar rechazos de Apple.

Preguntas frecuentes

¿Dónde poner una clave API secreta en una aplicación Expo?

En tu servidor, nunca en la app. La clave secret o service_role de Supabase, igual que la clave secreta de un proveedor de IA, debe quedarse solo del lado del servidor. La app llama a tu servidor, que controla al usuario y los límites antes de llamar al proveedor. Comprueba que ninguna de estas claves aparezca en el bundle móvil ni en los registros accesibles para el cliente.

¿Un archivo .env protege mi clave API en Expo?

Por sí solo, no. Una variable con el prefijo EXPO_PUBLIC_ está pensada para el código de la app y no debe contener un secreto de servidor. Expo explica que estos valores se integran en el JavaScript compilado y los usuarios de la aplicación pueden leerlos. Así que mover una clave a un archivo .env no basta para protegerla.

¿Qué diferencia hay entre una clave API pública y una clave secreta?

Una clave pública está pensada para ir dentro de la app: identifica el proyecto, pero no sustituye los permisos sobre los datos. Una clave secreta autoriza acciones privilegiadas y se reserva para entornos de confianza. En Supabase, la clave publishable, o la antigua clave anon, puede quedarse en la app si los permisos están bien configurados. Las claves secret y service_role se quedan en el servidor.

¿Cómo llamar a una API de IA desde una app Expo sin exponer la clave?

Pasa la llamada por tu servidor: la app llama al servidor, que llama al proveedor y luego devuelve la respuesta a la app. La clave secreta se queda en el servidor. Este también debe verificar la sesión, limitar las solicitudes repetidas y devolver un error comprensible si el proveedor no responde. El cliente no decide por sí mismo que un usuario tiene acceso de pago.

¿Cómo comprobar que cada usuario solo ve sus propios datos?

Prepara dos cuentas de prueba que controles, con una nota fácil de reconocer en cada una. Desde la cuenta A, intenta leer, modificar y crear en nombre de la cuenta B, y luego abrir el archivo privado de B. Haz también las pruebas sin sesión: cada solicitud debe ser rechazada o no revelar nada. Anota el resultado real, porque «las reglas están activadas» no es un resultado de prueba.

¿Cómo pedirle a una IA que revise las claves de mi aplicación?

Pídele que haga un inventario de las variables del código móvil y del servidor, mostrando solo sus nombres, sin pegar tus valores secretos. Pídele también que identifique las llamadas privilegiadas presentes del lado del cliente y que proponga una prueba con dos cuentas de prueba. Prohíbele cualquier rotación de claves o cambio en producción sin validación. Su respuesta no sustituye la ejecución de las pruebas.