¿Qué credenciales no deben guardarse en una app móvil?

01 /Diseña la aplicación contando con que puede inspeccionarse

Cuando publicas una app para Android o iOS, cada usuario recibe una copia de su código ejecutable y sus recursos. No recibe el código fuente bien ordenado, pero con herramientas corrientes se pueden recuperar cadenas de texto, archivos de configuración, direcciones de servicios y una aproximación bastante útil de la estructura del programa. Para buscar un token o repetir una petición ni siquiera hace falta reconstruir la app completa.

La ofuscación dificulta el análisis al eliminar, por ejemplo, nombres comprensibles del código. Sin embargo, no protege de forma fiable un valor que la propia app necesita leer. Por eso, debes contar con que el cliente puede inspeccionarse y comprobar los permisos en un sistema que controles, como el servidor.

02 /Qué puede revelar una app descompilada

Una revisión suele empezar por abrir el paquete de la app, examinar sus recursos y buscar texto. Pueden aparecer direcciones del servidor, identificadores de analítica, configuración de Firebase, opciones de funciones y credenciales incluidas por error al compilar. También se pueden observar las peticiones de la app. Una acción con permisos elevados no debe depender únicamente de un valor incluido en todas las copias del cliente.

El almacenamiento durante la ejecución exige el mismo cuidado. Un token del usuario autenticado tiene que llegar al dispositivo; no se trata de volverlo invisible para siempre. Hay que darle poco alcance y una vida corta, guardarlo con el almacenamiento protegido de la plataforma, enviarlo por TLS y hacer que el servidor compruebe en cada petición qué puede hacer ese usuario.

Dividir una clave entre varias cadenas, codificarla o descargarla al iniciar puede dificultar una búsqueda básica. El valor completo, sin embargo, debe estar disponible cuando se usa. Estas medidas complican su extracción, pero no permiten tratarlo como una credencial privada del servidor.

03 /Por qué una clave API de Firebase puede ser pública

Si abres una app Android con Firebase, normalmente encontrarás una clave API en google-services.json; una app de Apple lleva una configuración equivalente. Muchos informes la marcan como problema, pero Firebase explica que esas claves son públicas por diseño cuando están restringidas a sus APIs. Identifican el proyecto. No autorizan a un usuario a leer Firestore, Realtime Database o Cloud Storage.

Firebase Security Rules controla el acceso a los datos según la identidad y los permisos del usuario. App Check añade una señal sobre el origen de las peticiones: un servicio compatible puede rechazar las que no procedan de una instancia verificada de la app. Estos controles siguen siendo necesarios aunque se oculte la clave de Firebase.

El matiz importa. En el mismo proyecto de Google Cloud puede haber otras claves de servicios que cobran o autorizan por clave. Una clave válida para mapas, pagos, correo o una API de IA generativa sí puede tener valor para un atacante. Separa las claves, restringe cada una a la API y la aplicación previstas, fija cuotas razonables y coloca detrás de tu servidor cualquier servicio que requiera un secreto de verdad.

Gemini lo dejó claro. En febrero de 2026, Truffle Security mostró que activar la API de Gemini en un proyecto de Google Cloud permitía que las claves sin restricciones de ese proyecto, incluidas las ya publicadas para Maps o Firebase, llamaran a Gemini, accedieran a los archivos subidos y generaran cargos. La documentación de Gemini indica ahora que la API rechaza las claves estándar sin restricciones, y Firebase advierte que nunca se incluya la Gemini Developer API entre las APIs permitidas de una clave pública. Limita cada clave pública a las APIs que usa de verdad y llama a Gemini desde tu servidor o mediante Firebase AI Logic con App Check.

• Firebase: claves API de los proyectos ↗
• Truffle Security: claves API de Google y Gemini ↗
• Google AI: claves de la API de Gemini ↗
• Firebase AI Logic ↗

04 /Pon la decisión de seguridad en el servidor

Imagina una app de reservas que muestra horarios disponibles y permite elegir uno. Puede conocer la dirección pública de la API y recibir un token del usuario autenticado. El servidor debe comprobar que el horario sigue libre, fijar el precio válido y realizar cualquier llamada al proveedor de pagos que necesite una clave privada.

El servidor recibe la petición, verifica al usuario, comprueba la disponibilidad y el precio actuales, ejecuta la acción privilegiada con una credencial que no sale de allí y devuelve solo el resultado. El ejemplo es ficticio, pero la frontera es la misma en un portal de clientes, una app de almacén o un producto por suscripción.

Las comprobaciones en el cliente siguen mejorando la experiencia: desactivar un botón inválido, detectar una fecha mal escrita o explicar por qué algo no está disponible. Toda comprobación que afecte a la seguridad debe repetirse en el servidor, donde una app modificada no pueda saltársela.

Si el backend se conecta con sistemas del negocio, revisa también cómo separar la red y limitar el acceso entre equipos.

05 /Qué aportan App Check, Play Integrity y App Attest

La autorización responde a si este usuario puede realizar esta acción. La integridad de la app responde a otra pregunta: ¿parece que la petición viene de una instancia auténtica y sin modificar? Firebase App Check puede apoyarse en Play Integrity en Android y en App Attest o DeviceCheck en plataformas Apple para proporcionar esa señal a Firebase o a tu propio backend.

Estos controles reducen el abuso automatizado y algunas peticiones de apps copiadas o modificadas, pero pueden fallar. Hay dispositivos no compatibles o comprometidos, el servicio de verificación puede quedar indisponible y un usuario malicioso puede usar una app legítima. Activa la comprobación gradualmente, supervisa sus resultados y define qué ocurrirá durante un fallo. Mantén también autenticación, autorización, límites de uso y registros.

Prioriza las comprobaciones más exigentes en acciones con mayor riesgo o coste: canjear una promoción, enviar una petición cara a un modelo de IA, descargar contenido de pago o cambiar el destino de un cobro. Consultar un catálogo público puede tener otras necesidades de control.

06 /Una revisión práctica antes de publicar

Antes del lanzamiento, inspecciona el mismo archivo que instalarán los usuarios, no solo el repositorio. Busca credenciales y material privado en el paquete compilado; enumera todos los servicios externos; confirma que cada clave es pública por diseño o está restringida al mínimo; y prueba las peticiones importantes sin pasar por la interfaz de la app.

Después prueba los permisos con dos cuentas normales. ¿Puede una leer o cambiar los registros de la otra modificando un identificador? ¿Puede cualquiera llamar a una ruta administrativa? ¿Las reglas de Firebase tienen pruebas de casos denegados además de los que funcionan? Por último, revisa registros, cuotas y alertas: cuesta confiar en producción en un control que no puedes observar.

• No hay cuentas de servicio, secretos de firma, claves de pago ni claves privadas en el paquete.
• Cada clave de cliente tiene responsable, finalidad, restricciones y plan de rotación.
• El servidor vuelve a comprobar identidad, propiedad, roles, precios y derechos de acceso.
• Las reglas de Firebase deniegan por defecto y tienen pruebas de accesos permitidos y rechazados.
• La certificación de la app complementa, pero nunca sustituye, autenticación y autorización.
• Límites, presupuestos y alertas hacen visible el abuso antes de que llegue la factura.

07 /Si encuentras un secreto real en una app ya publicada

Trata ese valor como expuesto. Revócalo o rótalo primero, usando el procedimiento de solapamiento seguro del proveedor si un cambio inmediato rompería producción. Revisa accesos, facturación y cambios realizados con la credencial; conserva las pruebas necesarias para entender durante cuánto tiempo estuvo expuesta; y avisa a quien corresponda si pudo afectar a datos o cuentas.

Para corregirlo, mueve la operación que necesita esa credencial al servidor o a una función gestionada. Comprueba allí los permisos del usuario y concede al servicio únicamente los accesos necesarios. Ocultar mejor la misma credencial en otra versión de la app no resuelve el problema.

Para entender cómo cambia esta revisión con modelos más capaces, lee agentes de hacking con IA: avances reales y límites.