¿Cómo garantizar la seguridad de una app móvil y qué controles son obligatorios antes del lanzamiento?

Si usan JWT, mantengan la duración de los tokens muy corta; por ejemplo, 15 minutos para el access token y 7 días para el refresh token. Además, asegúrense de no haber dejado el archivo `.env` en la compilación de la app. A veces los desarrolladores dejan incrustadas en el código cliente las contraseñas de bases de datos de pruebas o claves de API de servicios de terceros.

Tareas urgentes antes del lanzamiento: 1) Añadir detección de root/jailbreak para que la app alerte o bloquee en dispositivos modificados. 2) Activar el bloqueo de capturas de pantalla y el oscurecimiento de pantalla al pasar a segundo plano. 3) Evitar que los mensajes de error devuelvan rutas del servidor o logs de la base de datos.

Hagan esta prueba ustedes mismos ahora mismo: instalen un analizador de tráfico de red en la computadora, conecten el teléfono a la misma red wifi y pasen el tráfico por la compu. Si pueden leer en texto plano en la pantalla los precios y desgloses de facturas que van y vienen del teléfono, significa que no tienen SSL Pinning.

La gente se obsesiona tanto con proteger la parte móvil que se olvida de la puerta principal: la API. Aunque blindes tu app móvil por completo, un atacante ni siquiera la va a usar; tirará peticiones directo a tu API. Nunca tomen la app móvil como un entorno de confianza, toda la lógica se tiene que validar en el servidor.

El año pasado nos pasó con una app B2B mayorista similar. Al generar un pedido, un distribuidor interceptó el tráfico y mandó a la API el precio unitario del producto a 15 TL en vez de 150 TL. En la pantalla del móvil el campo del precio estaba bloqueado, pero el backend procesó el pedido con el precio que le llegó. Nos dimos cuenta dos semanas después en el recuento del almacén. Revisen dos veces las validaciones de precios en el servidor.

no se olviden de apagar los logs de debug en la app a veces por el logcat salen todos los datos de usuario y tokens en texto plano limpien los console log antes de subir a la tienda.

Dado que su aplicación maneja datos financieros de personas jurídicas y empresas unipersonales que constituyen secreto comercial, cualquier filtración generará la obligación de notificar la brecha ante la Autoridad de Protección de Datos Personales (KVKK). Por ello, es jurídicamente indispensable documentar y conservar el registro de todas las medidas de seguridad adoptadas.

o sea que con eso de la ingeniería inversa ¿los distribuidores o cualquiera pueden bajarse la app y ver todo el código fuente en su computadora? ¿Eso no lo bloquean en las revisiones de las tiendas?

Correcto.

Gracias, me ha servido de mucha ayuda.

No te olvides de: Si intentas cambiarlo todo a la vez, nada termina de asentarse.

Lo dejo como nota, por si sirve.

Os cuento lo que me pasó a mí, a ver si os sirve de ayuda. Las decisiones apresuradas son las que hay que corregir seis meses después.

no saabía eso.

A nosotros nos pasó esto. Intentar hacerlo solo es la vía más cara.

Espero que le sea útil.

hay tres cosas que revisar al hacer esto. en fin la seguridad no es absoluta; significa hacer que el ataquue no merezca la pena.

no tengáis miedo de preguntar quien no pregunta siempre paga más caro. yo seguiría por ese camino.

Yo pasé por esto, déjenme contarlo. La seguridad no es absoluta; significa hacer que el ataque no merezca la pena.

Corrijanme si me equivoco.

No te olvides de: Que todo el mundo haga algo no significa que sea lo correcto.

Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

La respuesta de arriba ha dado en el clavo. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí. Eso es todo disculpa si me he extendido demasiado.