Una app mòbil pot guardar un secret?

01 /La resposta curta: dona per fet que el client es pot inspeccionar

Quan publiques una app per a Android o iOS, cada usuari rep una còpia del codi executable i dels recursos. No rep el codi font ben ordenat, però amb eines corrents es poden recuperar cadenes de text, fitxers de configuració, adreces de serveis i una aproximació força útil a l'estructura del programa. Per buscar un testimoni d'accés o repetir una petició ni tan sols cal reconstruir tota l'app.

Ofuscar continua sent útil: elimina noms entenedors i encareix l'anàlisi. És un obstacle, no una caixa forta. Si l'app necessita llegir un valor, algú que controli el dispositiu acabarà podent-lo llegir. La regla duradora és senzilla: dissenya el client com si fos observable i deixa l'autoritat en un sistema que controlis.

02 /Què pot revelar realment una app descompilada

La primera revisió acostuma a ser poc espectacular. S'obre el paquet, se'n llisten els recursos i es busquen cadenes. Hi poden aparèixer adreces del servidor, identificadors d'analítica, la configuració de Firebase, indicadors de funcions i credencials que algú va copiar en un fitxer de compilació. Després s'observen les peticions de l'app. Si una acció privilegiada depèn només d'un valor inclòs al client, el problema no és l'habilitat del descompilador: la frontera de confiança és al lloc equivocat.

L'emmagatzematge durant l'execució exigeix la mateixa cura. Un testimoni de l'usuari autenticat ha d'arribar al dispositiu; no es tracta de fer-lo invisible per sempre. Cal donar-li poc abast i una vida curta, desar-lo amb l'emmagatzematge protegit de la plataforma, enviar-lo per TLS i fer que el servidor comprovi a cada petició què pot fer aquell usuari.

Tampoc no convé confondre dificultat amb protecció. Dividir una clau entre diverses cadenes, codificar-la o descarregar-la en arrencar pot amagar-la d'una cerca bàsica, però el valor complet ha d'existir quan es fa servir. Aquestes tècniques frenen el rastreig massiu; no converteixen un secret compartit en un de privat.

03 /L'excepció de la clau API de Firebase i què no justifica

Si obres una app Android amb Firebase, normalment trobaràs una clau API a google-services.json; una app d'Apple porta una configuració equivalent. Molts informes la marquen com a problema, però Firebase explica que aquestes claus són públiques per disseny quan estan restringides a les seves API. Identifiquen el projecte. No autoritzen un usuari a llegir Firestore, Realtime Database o Cloud Storage.

L'accés es controla amb les Firebase Security Rules, aplicades segons la identitat de l'usuari. App Check hi afegeix un altre senyal: ajuda un servei compatible a rebutjar trànsit que no prové d'una instància verificada de la teva app. Amagar la clau de Firebase no substitueix cap d'aquests controls.

El matís importa. Al mateix projecte de Google Cloud hi pot haver altres claus de serveis que cobren o autoritzen per clau. Una clau vàlida per a mapes, pagaments, correu o una API d'IA generativa sí que pot tenir valor per a un atacant. Separa les claus, restringeix cadascuna a l'API i l'aplicació previstes, fixa quotes raonables i posa darrere del servidor qualsevol servei que requereixi un secret de debò.

04 /Posa la decisió de seguretat al servidor

Imagina una app de reserves que mostra hores disponibles i deixa que un client en triï una. L'app pot conèixer l'adreça pública de l'API i portar un testimoni del client autenticat. El que no hauria de fer és decidir que una hora continua lliure, posar-se el seu propi preu o cridar el proveïdor de pagaments amb la teva clau privada.

El servidor rep la petició, verifica l'usuari, comprova la disponibilitat i el preu actuals, executa l'acció privilegiada amb una credencial que no en surt i retorna només el resultat. L'exemple és fictici, però la frontera és la mateixa en un portal de clients, una app de magatzem o un producte per subscripció.

Les comprovacions al client continuen millorant l'experiència: desactivar un botó no vàlid, detectar una data mal escrita o explicar per què una cosa no està disponible. Tota comprovació que afecti la seguretat s'ha de repetir al servidor, on una app modificada no se la pugui saltar.

Si el servidor es connecta amb sistemes del negoci, revisa també com separar la xarxa i limitar l'accés entre equips.

05 /Què aporten App Check, Play Integrity i App Attest

L'autorització respon si aquest usuari pot fer aquesta acció. La integritat de l'app respon una altra pregunta: sembla que la petició ve d'una instància autèntica i sense modificar? Firebase App Check es pot basar en Play Integrity a Android i en App Attest o DeviceCheck a les plataformes Apple per proporcionar aquest senyal a Firebase o al teu propi servidor.

Serveix per reduir l'abús automatitzat, els clients copiats i una part del trànsit d'apps modificades. No és una prova infal·lible. Hi pot haver dispositius no compatibles o compromesos, el servei de certificació pot fallar i un usuari maliciós pot fer servir una app legítima. Activa el control gradualment i amb observació, decideix què passa quan no està disponible i mantén l'autenticació, l'autorització, els límits i els registres habituals.

Aplica les comprovacions més estrictes a les accions amb més risc: reclamar una promoció, llançar una petició cara a un model d'IA, baixar contingut de pagament o canviar el destí d'un cobrament són millors candidats que consultar un catàleg públic.

06 /Una revisió pràctica abans de publicar

Abans del llançament, inspecciona el mateix fitxer que instal·laran els usuaris, no només el repositori. Busca credencials i material privat al paquet compilat; enumera tots els serveis externs; confirma que cada clau és pública per disseny o està restringida al mínim; i prova les peticions importants sense passar per la interfície de l'app.

Després prova els permisos amb dos comptes normals. Un pot llegir o canviar els registres de l'altre modificant un identificador? Qualsevol pot cridar una ruta administrativa? Les regles de Firebase tenen proves de casos denegats a més dels que funcionen? Finalment, revisa registres, quotes i alertes: costa confiar en producció en un control que no pots observar.

• No hi ha comptes de servei, secrets de signatura, claus de pagament ni claus privades al paquet.
• Cada clau de client té responsable, finalitat, restriccions i pla de rotació.
• El servidor torna a comprovar identitat, propietat, rols, preus i drets d'accés.
• Les regles de Firebase deneguen per defecte i tenen proves d'accessos permesos i rebutjats.
• La certificació de l'app complementa, però no substitueix mai, l'autenticació i l'autorització.
• Límits, pressupostos i alertes fan visible l'abús abans que arribi la factura.

07 /Si trobes un secret real en una app ja publicada

Tracta aquell valor com a exposat. Revoca'l o rota'l primer, fent servir el procediment de solapament segur del proveïdor si un canvi immediat interrompés producció. Revisa els accessos, la facturació i els canvis fets amb la credencial; conserva les proves necessàries per entendre quant de temps va estar exposada; i avisa qui correspongui si ha pogut afectar dades o comptes.

La solució permanent és d'arquitectura: posa la crida privilegiada darrere d'un servidor o una funció gestionada, autoritza-hi l'usuari i dona a aquell entorn només els permisos que necessita. Publicar una altra versió amb el mateix secret més dissimulat manté el mateix problema.

Per entendre com canvia aquesta revisió amb models més capaços, llegeix agents de hacking amb IA: avenços reals i límits.