Auditoría de seguridad de apps móviles y APIs

Una app móvil casi nunca está sola. Detrás de cada pantalla hay una API que entrega y recibe datos, y la mayoría de los problemas serios de seguridad aparecen en esa conversación: una API que entrega datos de otro usuario si cambias un número en la petición, un token que no expira, una llave guardada dentro de la app.

Esta guía explica qué es una auditoría de seguridad de una app móvil y su API, qué se revisa, cómo prepararte y qué deberías recibir al final.

Qué es una auditoría de seguridad de una app y su API

Es una revisión técnica, hecha con autorización del dueño del sistema, que busca debilidades explotables en tres lugares:

La app instalada en el teléfono (Android, iOS o ambas): qué guarda, cómo se protege y qué revela si alguien la analiza.
La comunicación entre la app y el servidor: cómo viajan los datos y si pueden interceptarse o manipularse.
La API que sostiene la app: autenticación, autorización, validación de datos y lógica de negocio.

Se diferencia de un escaneo automático en que una persona entiende cómo funciona tu app y prueba lo que una herramienta no ve, como si un usuario puede ver los pedidos de otro o saltarse un paso de pago.

Por qué la autorización escrita es lo primero

Probar la seguridad de un sistema sin permiso de su dueño puede ser un delito. Por eso toda auditoría seria parte con una autorización escrita que define qué se prueba, desde dónde, en qué fechas y quién es el contacto ante cualquier imprevisto. Si tu app usa servicios de terceros (nube, pasarela de pago, proveedores de identidad), el alcance debe dejar claro qué partes son tuyas y cuáles no se tocan.

Qué se revisa: los estándares de referencia

Una buena auditoría sigue un método conocido, para que los resultados sean comparables y verificables. Los dos más usados son de OWASP, una fundación sin fines de lucro que publica guías abiertas de seguridad.

En la app: OWASP MASVS y MASTG

El OWASP MASVS (Mobile Application Security Verification Standard) define qué debe cumplir una app móvil segura, y la MASTG describe cómo probarlo. El MASVS organiza los controles en ocho grupos:

MASVS-STORAGE: qué datos guarda la app en el teléfono y cómo. Tokens, contraseñas o datos personales en archivos sin protección son un hallazgo frecuente.
MASVS-CRYPTO: uso correcto de la criptografía. Llaves escritas dentro del código o algoritmos obsoletos.
MASVS-AUTH: autenticación y autorización en la app y su relación con el servidor.
MASVS-NETWORK: comunicación segura, TLS bien configurado y validación de certificados.
MASVS-PLATFORM: interacción con el sistema operativo: permisos, enlaces profundos, componentes expuestos a otras apps, WebViews.
MASVS-CODE: calidad del código, dependencias vulnerables, validación de entradas y actualizaciones.
MASVS-RESILIENCE: resistencia a la ingeniería inversa y a la manipulación, cuando el modelo de negocio lo justifica.
MASVS-PRIVACY: qué datos personales recolecta la app, si son necesarios y si el usuario sabe lo que ocurre con ellos.

No todos los grupos pesan igual en todas las apps. Una app bancaria necesita más resiliencia que una app de reservas; una app de salud necesita más cuidado en almacenamiento y privacidad.

En la API: OWASP API Security Top 10

El OWASP API Security Top 10 (2023) resume los riesgos más frecuentes en APIs. Los que más aparecen en apps móviles son:

Autorización a nivel de objeto (API1). El usuario A pide /pedidos/1041, cambia el número a 1042 y recibe el pedido del usuario B. Es el hallazgo más común y uno de los más graves.
Autenticación deficiente (API2). Tokens que no expiran, recuperación de contraseña débil o intentos de ingreso sin límite.
Autorización a nivel de propiedad (API3). La API devuelve más campos de los que la app muestra, o acepta campos que el usuario no debería poder modificar, como su propio rol.
Consumo de recursos sin límite (API4). Sin límites de tasa, alguien puede generar costos o dejar la API fuera de servicio.
Autorización a nivel de función (API5). Un usuario común puede llamar a funciones de administración.
Mala configuración (API8) e inventario deficiente (API9). Versiones antiguas de la API aún expuestas, mensajes de error con detalles internos o documentación de desarrollo abierta en producción.

Cómo es el proceso

1. Alcance y autorización

Se define qué versión de la app se revisa (Android, iOS o ambas), qué ambiente (idealmente uno de pruebas igual a producción), qué endpoints de la API entran y cuáles quedan fuera. Se firma la autorización.

2. Preparación

Necesitarás entregar, según el tipo de revisión:

El instalador de la app (APK, AAB o build de pruebas para iOS).
Al menos dos cuentas de prueba por cada rol (por ejemplo, dos clientes y un administrador), para verificar que un usuario no pueda acceder a los datos de otro.
Documentación de la API si existe (por ejemplo, un archivo OpenAPI).
Un contacto técnico disponible durante las pruebas.

Mientras más información entregues, más profunda y eficiente es la revisión. Una prueba sin información (“caja negra”) simula a un atacante externo, pero gasta tiempo en descubrir lo que tu equipo podría explicar en una reunión.

3. Pruebas

Se analiza la app instalada y su contenido, se intercepta el tráfico entre la app y la API en un ambiente controlado y se prueban los endpoints con cada rol. Cada hallazgo se registra con la evidencia necesaria para reproducirlo.

4. Informe

El resultado se entrega en dos niveles:

Informe ejecutivo, para gerencia: qué riesgos existen, qué tan graves son y qué corregir primero.
Informe técnico, para el equipo de desarrollo: cada hallazgo con su evidencia, cómo reproducirlo y cómo corregirlo.

5. Corrección y re-test

Tu equipo corrige y, después, se verifica que las correcciones funcionen y no hayan abierto otro problema. Sin este paso, el informe es una lista de pendientes y no una mejora comprobada.

Qué hace bueno un informe

Hallazgos priorizados por riesgo real, no por la cantidad. Diez observaciones menores no pesan lo que un solo acceso a datos de otros usuarios.
Evidencia reproducible: la petición, la respuesta y los pasos.
Recomendaciones concretas para tu stack, no genéricas.
Sin falsos positivos de herramientas automáticas copiados sin verificar.
Honestidad sobre el alcance: qué no se revisó y por qué. Una auditoría reduce riesgos; no demuestra que un sistema no tenga fallas.

Cuándo conviene hacer una auditoría

Antes de publicar una app nueva o una versión con cambios grandes en autenticación, pagos o datos personales.
Cuando un cliente o socio lo exige, por ejemplo en un cuestionario de seguridad de proveedores.
Después de un incidente, para entender qué pasó y qué más podría estar expuesto.
De forma periódica, si la app trata datos sensibles o dinero y cambia seguido.

Si tu app trata datos personales, una auditoría también es parte de verificar que tus medidas de seguridad funcionan, algo que la Ley 21.719 pide de forma regular.

Errores comunes

Auditar solo la app y no la API. La mayoría de los hallazgos graves están en el servidor.
Confiar en que la app oculta botones. Si la API no valida permisos, ocultar un botón en la app no protege nada.
Guardar secretos dentro de la app. Todo lo que va dentro del instalador puede extraerse. Las llaves de servicios de terceros deben vivir en el servidor.
Auditar una versión que ya no es la de producción. Acuerda qué versión se revisa y congélala durante las pruebas.

Preguntas frecuentes

¿Cuánto demora una auditoría?

Depende del tamaño de la app, la cantidad de endpoints y roles, y si se revisan Android e iOS. Una app acotada toma menos que una plataforma con muchos perfiles de usuario. El plazo se define en la propuesta, después de conocer el alcance.

¿Se prueba en producción?

Se prefiere un ambiente de pruebas equivalente. Si solo existe producción, se acuerdan límites claros para no afectar a usuarios reales ni sus datos.

¿Sirve un escáner automático?

Ayuda a encontrar problemas conocidos, pero no entiende tu lógica de negocio. Los fallos de autorización entre usuarios, los más graves en APIs, casi siempre requieren pruebas manuales.

Cómo te podemos ayudar

En Kalfun Tech hacemos auditorías de apps móviles y APIs: revisamos la app instalada, su comunicación con el servidor y la API que la sostiene, y entregamos un informe ejecutivo, un informe técnico y un re-test a 30 días para verificar las correcciones. Trabajamos solo con autorización escrita del dueño del sistema. Si necesitas presentar los resultados en un cuestionario de un cliente, revisa también nuestra guía para responder un cuestionario de ciberseguridad.

¿Quieres revisar tu app antes de su próxima versión? Conversemos.