¿Puede una app móvilguardar un secreto?

01 /La respuesta corta: da por hecho que el cliente se puede inspeccionar

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.

Ofuscar sigue siendo útil: elimina nombres comprensibles y encarece el análisis. Es un obstáculo, no una caja fuerte. Si la app necesita leer un valor, alguien que controle el dispositivo acabará pudiendo leerlo. La regla duradera es sencilla: diseña el cliente como si fuera observable y deja la autoridad en un sistema que controles.

02 /Qué puede revelar realmente una app decompilada

La primera revisión suele ser poco espectacular. Se abre el paquete, se listan sus recursos y se buscan cadenas. Ahí pueden aparecer direcciones del servidor, identificadores de analítica, la configuración de Firebase, banderas de funciones y credenciales que alguien copió en un archivo de compilación. Después se observan las peticiones que hace la app. Si una acción privilegiada depende solo de un valor incluido en el cliente, el problema no es la habilidad del decompilador: la frontera de confianza está en el lugar equivocado.

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.

Tampoco conviene confundir molestia con protección. Partir una clave entre varias cadenas, codificarla o descargarla al arrancar puede ocultarla de una búsqueda básica, pero el valor completo tiene que existir cuando se usa. Estas técnicas frenan el rastreo masivo; no convierten un secreto compartido en uno privado.

03 /La excepción de la clave API de Firebase, y lo que no justifica

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.

Las cerraduras son las Firebase Security Rules, aplicadas según la identidad del usuario. App Check añade otra señal: ayuda a que un servicio compatible rechace tráfico que no procede de una instancia verificada de tu app. Ocultar la clave de Firebase no sustituye ninguno de estos controles.

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.

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

Imagina una app de reservas que muestra horas disponibles y deja que un cliente elija una. La app puede conocer la dirección pública de la API y llevar un token del cliente autenticado. Lo que no debería hacer es decidir que una hora sigue libre, ponerse su propio precio o llamar al proveedor de pagos con tu 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.

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.

Sirve para reducir abuso automatizado, clientes copiados y parte del tráfico de apps modificadas. No es una prueba infalible. Puede haber dispositivos no compatibles o comprometidos, el servicio de certificación puede fallar y un usuario malicioso puede manejar una app legítima. Activa el control de forma gradual y observada, decide qué ocurre cuando no está disponible y mantén autenticación, autorización, límites y registros normales.

Reserva las comprobaciones más fuertes para momentos valiosos en vez de convertir cada pantalla inocua en una fortaleza: reclamar una promoción, lanzar una petición cara a un modelo de IA, descargar contenido de pago o cambiar el destino de un cobro son mejores candidatos que consultar un catálogo público.

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.

La solución permanente es de arquitectura: coloca la llamada privilegiada detrás de un servidor o una función gestionada, autoriza allí al usuario y da a ese entorno solo los permisos que necesita. Publicar otra versión con el mismo secreto mejor disimulado solo vuelve a poner el contador a cero.