Usé las apps del gobierno un mes. Esto encontré.
No las usé como ciudadano. No las usé para hacer trámites. Las usé como perito informático forense con 17 años de experiencia, con ojo de auditor, con la mentalidad de alguien que busca lo que no debería encontrar.
Y encontré lo que no debería haber encontrado.
Credenciales transmitidas en texto plano. Sesiones que no expiraban durante horas. Endpoints de API sin autenticación. Certificados SSL mal configurados. Datos personales almacenados localmente en el dispositivo sin cifrado. Información fiscal de contribuyentes accesible a través de manipulación de parámetros. Y un patrón recurrente que explica por qué todo esto pasa: contratistas temporales que desarrollan las aplicaciones, entregan el producto y desaparecen, dejando el código sin mantenimiento, sin actualizaciones y sin nadie que responda cuando se descubre una vulnerabilidad.
Voy a documentar lo que encontré. Voy a documentarlo con el rigor técnico que requiere y con la prudencia que exige la divulgación responsable. No voy a publicar exploits reproducibles. No voy a publicar endpoints específicos que permitan a alguien replicar los hallazgos. Voy a documentar los patrones de vulnerabilidad, las categorías de riesgo y las implicaciones para los millones de mexicanos cuyos datos están en juego.
Porque lo que está en juego no es abstracto. Son los datos fiscales de millones de contribuyentes. Son los historiales médicos de millones de derechohabientes. Son los datos de identidad de millones de ciudadanos. Y están en aplicaciones que no cumplen con los estándares mínimos de seguridad que cualquier empresa privada seria exige a sus desarrolladores.
Contribuyente que me lee: cada vez que abres la app del SAT en tu teléfono, confías en que tu información fiscal está protegida. Este artículo te va a decir si esa confianza está justificada.
Derechohabiente del IMSS que me lee: cada vez que consultas tus semanas cotizadas o tu historial médico en la app del IMSS, confías en que nadie más puede ver esa información. Este artículo te va a decir si esa confianza está justificada.
La metodología: qué hicimos y qué no hicimos
Necesito ser claro sobre la metodología porque la línea entre auditoría de seguridad y acceso no autorizado es una línea que en México está definida por el Código Penal Federal, y respetarla es tanto una obligación legal como un imperativo ético.
Lo que hicimos fue analizar las aplicaciones móviles del gobierno mexicano como usuarios. Descargamos las apps de las tiendas oficiales de Google Play y App Store. Las instalamos en dispositivos de prueba. Las usamos con cuentas propias — cuentas reales de miembros del equipo de Duriva. Observamos el comportamiento de las apps. Analizamos el tráfico de red que generaban. Examinamos los datos que almacenaban localmente en el dispositivo. Revisamos la configuración de seguridad de las comunicaciones.
Lo que no hicimos fue intentar acceder a sistemas del gobierno. No intentamos explotar vulnerabilidades para obtener acceso no autorizado. No intentamos acceder a datos de otros usuarios. No ejecutamos ataques contra la infraestructura del gobierno. Nos limitamos a observar lo que las apps hacían en nuestros propios dispositivos, con nuestros propios datos, desde nuestra propia red.
Esa distinción es importante. Todo lo que voy a documentar fue observado de forma pasiva — analizando el comportamiento de las apps como usuario, no como atacante. Si lo que observamos de forma pasiva ya es preocupante, lo que un atacante activo podría encontrar es otra dimensión.
Las herramientas que usamos son estándar en auditorías de seguridad de aplicaciones móviles: un proxy de interceptación para analizar el tráfico de red (tipo Burp Suite o mitmproxy), herramientas de análisis estático para examinar el código de la aplicación, y herramientas de análisis del almacenamiento local del dispositivo. Todo legal. Todo documentado. Todo dentro del marco de una auditoría de seguridad defensiva.
Hallazgo 1: Transmisión de datos sensibles sin cifrado adecuado
Esto es básico. Tan básico que es vergonzoso tener que reportarlo en 2026.
HTTPS — la versión cifrada del protocolo HTTP — es el estándar mínimo para cualquier comunicación web que involucre datos sensibles. Cuando accedes a tu banco en línea, la conexión es HTTPS. Cuando compras algo en Amazon, la conexión es HTTPS. Cuando inicias sesión en tu correo electrónico, la conexión es HTTPS. El cifrado TLS que proporciona HTTPS es lo que impide que alguien que intercepte tu tráfico de red pueda leer el contenido de la comunicación.
Lo que encontramos en varias apps gubernamentales es que, aunque la conexión principal era HTTPS, había componentes de las aplicaciones que hacían llamadas a endpoints en HTTP plano. Sin cifrar. Sin TLS. En texto claro.
¿Qué significa eso en la práctica? Que si un usuario está conectado a una red WiFi pública — en un café, en un aeropuerto, en una plaza comercial — y abre una de estas apps, un atacante en la misma red puede interceptar parte del tráfico y ver la información que se transmite. Si esa información incluye credenciales de acceso, datos fiscales o datos personales, el atacante los tiene.
Pero el problema va más allá del HTTP plano. Incluso en las conexiones HTTPS, encontramos configuraciones de TLS deficientes. Versiones obsoletas de TLS (TLS 1.0 y 1.1, que están oficialmente deprecadas y tienen vulnerabilidades conocidas). Cipher suites débiles que son susceptibles a ataques de descifrado. Y en algunos casos, la app no validaba correctamente el certificado del servidor — lo que la hace vulnerable a ataques de man-in-the-middle donde un atacante presenta un certificado falso y la app lo acepta sin quejarse.
Certificate pinning — la práctica de que la app solo acepte el certificado específico del servidor del gobierno, rechazando cualquier otro — no estaba implementado en la mayoría de las apps que analizamos. Certificate pinning es una defensa estándar contra man-in-the-middle en aplicaciones móviles. Los bancos lo implementan. Las apps de comercio electrónico lo implementan. Las apps de mensajería lo implementan. Las apps del gobierno mexicano, en su mayoría, no.
Hallazgo 2: Almacenamiento local inseguro
Cuando instalas una app en tu teléfono, la app almacena datos localmente en el dispositivo. Esto es normal y necesario — la app necesita guardar tokens de sesión, preferencias del usuario, cachés de datos para funcionar sin conexión, etc.
El problema es cómo se almacenan esos datos. En un dispositivo móvil, los datos de una app están protegidos por el sandbox del sistema operativo — en teoría, solo la app puede acceder a sus propios datos. Pero si el dispositivo está comprometido (rooteado o con jailbreak), si el usuario conecta el dispositivo a una computadora para hacer respaldo, si un malware obtiene permisos elevados, o si alguien tiene acceso físico al dispositivo, los datos almacenados localmente son accesibles.
Por eso, los datos sensibles que una app almacena localmente deben estar cifrados. No solo protegidos por el sandbox del sistema operativo. Cifrados con claves que no están hardcodeadas en el código de la app.
Lo que encontramos en varias apps gubernamentales es lo siguiente:
Tokens de sesión almacenados en texto plano
El token de sesión es lo que le dice al servidor «este usuario ya se autenticó, no le pidas la contraseña otra vez.» Si un atacante obtiene el token de sesión, puede suplantar al usuario sin necesidad de conocer sus credenciales. Los tokens de sesión deben almacenarse en el Keychain de iOS o en el KeyStore de Android — almacenes seguros, cifrados, diseñados específicamente para este propósito. En varias de las apps que analizamos, los tokens estaban en SharedPreferences (Android) o en archivos plist (iOS) sin cifrar.
Datos personales en caché sin cifrar
Cuando la app consulta información del usuario — datos fiscales en el caso del SAT, historial médico en el caso del IMSS –, esa información se almacena en un caché local para que la próxima vez que el usuario la consulte, cargue más rápido. Eso es comprensible desde el punto de vista de usabilidad. Pero si ese caché contiene información fiscal detallada, historial de declaraciones, datos de salud o información de identidad, y está almacenada sin cifrar en el almacenamiento del dispositivo, cualquier persona con acceso al dispositivo puede leerla.
Logs de depuración con información sensible
En varias apps encontramos logs de depuración — registros que los desarrolladores usan durante el desarrollo para diagnosticar errores — que no fueron eliminados antes de publicar la app. Esos logs contenían URLs completas con parámetros, respuestas del servidor con datos del usuario y, en algunos casos, credenciales o tokens en texto plano. Los logs de depuración son herramientas de desarrollo. No deberían existir en una app de producción. Su presencia indica que la app no pasó por un proceso de revisión de seguridad antes de ser publicada.
Hallazgo 3: Gestión de sesiones deficiente
La gestión de sesiones es uno de los aspectos más críticos de la seguridad de una aplicación. Una sesión mal gestionada permite que un atacante se haga pasar por un usuario legítimo sin conocer sus credenciales.
Lo que encontramos:
Sesiones que no expiraban en tiempos razonables
En una de las apps que analizamos, la sesión permanecía activa durante más de 8 horas después de la última interacción. Eso significa que si un usuario abría la app a las 9 de la mañana, consultaba su información y no volvía a usar la app en todo el día, a las 5 de la tarde la sesión seguía activa. Si alguien tomaba el teléfono del usuario a las 4 de la tarde — un compañero de trabajo, un ladrón, un menor curioso –, podía acceder a toda la información del usuario sin necesidad de autenticarse.
Las mejores prácticas de seguridad indican que las sesiones de apps que manejan información sensible deben expirar después de un periodo corto de inactividad — 5 a 15 minutos para aplicaciones financieras y fiscales. 8 horas es un intervalo que no se justifica para una app que maneja información fiscal.
Tokens de sesión predecibles
En una de las apps, el token de sesión tenía un componente secuencial que podía ser predicho. Si el token de un usuario era, por ejemplo, «SESION-2024-00001234,» el siguiente token generado por el sistema era «SESION-2024-00001235.» Un atacante que obtuviera su propio token podía intentar predecir el token de otro usuario simplemente incrementando el número. Los tokens de sesión deben ser aleatorios, con suficiente entropía para que no puedan ser adivinados o predichos. Usar secuencias numéricas como tokens de sesión es un error de seguridad de primer semestre de ingeniería.
Falta de invalidación de sesión en el servidor
Cuando un usuario cierra sesión en la app, la app debería notificar al servidor para que el servidor invalide el token de sesión. Si el token no se invalida en el servidor, un atacante que haya capturado el token puede seguir usándolo incluso después de que el usuario haya cerrado sesión. En varias de las apps que analizamos, encontramos que el cierre de sesión era solo local — la app borraba el token del dispositivo, pero no notificaba al servidor. El token seguía siendo válido en el servidor durante horas.
Hallazgo 4: Endpoints de API expuestos
Las aplicaciones móviles modernas funcionan como interfaces que se comunican con servidores a través de APIs (Application Programming Interfaces). La app muestra los datos; la API los proporciona. La seguridad de la app depende, en gran medida, de la seguridad de la API.
Lo que encontramos al analizar el tráfico de las apps gubernamentales es que varias de las APIs tenían problemas serios:
Endpoints sin autenticación
Encontramos endpoints de API que devolvían información sin requerir un token de sesión válido. No toda la información era sensible — algunos endpoints devolvían catálogos públicos, datos de configuración, etc. Pero algunos sí devolvían datos que no deberían ser accesibles sin autenticación.
Insecure Direct Object References (IDOR)
Este es un tipo de vulnerabilidad clásica donde la API usa un identificador directo — como un número de RFC, un CURP o un número de seguridad social — como parámetro para recuperar información. Si la API no verifica que el usuario autenticado tiene derecho a ver la información asociada a ese identificador, un atacante puede cambiar el parámetro y ver la información de otro usuario.
Para ser claro: no intentamos explotar esta vulnerabilidad para acceder a datos ajenos. Lo que encontramos fue que la estructura de las URLs y los parámetros de las APIs sugerían fuertemente que la verificación de autorización era deficiente o inexistente. Un parámetro de consulta que era literalmente el RFC del contribuyente, sin ningún token de autorización adicional que verificara que el solicitante tenía derecho a ver esa información, es una señal de alerta roja.
Falta de rate limiting
Las APIs no tenían límites de velocidad. Un atacante podía hacer miles de solicitudes por minuto sin ser bloqueado. Eso facilita ataques de fuerza bruta contra mecanismos de autenticación, enumeración de identificadores válidos y extracción masiva de datos.
Hallazgo 5: El problema de los contratistas temporales
Este hallazgo no es técnico. Es estructural. Y es quizá el más importante de todos porque explica por qué los cuatro hallazgos anteriores existen.
Las aplicaciones del gobierno mexicano, en su gran mayoría, no son desarrolladas por equipos internos de las dependencias. Son desarrolladas por contratistas externos. Empresas de desarrollo de software que ganan la licitación, desarrollan la aplicación, la entregan y se van.
Este modelo tiene problemas fundamentales de seguridad:
No hay continuidad
El contratista que desarrolló la app v1.0 no es necesariamente el mismo que desarrolla la v2.0. El conocimiento del código, de la arquitectura, de las decisiones de diseño, se pierde con cada cambio de contratista. Y con ese conocimiento se pierden también las consideraciones de seguridad que (si es que existieron) el contratista original incorporó.
No hay mantenimiento de seguridad
Las vulnerabilidades de seguridad se descubren después del despliegue, no antes. Una librería que era segura cuando se escribió el código puede tener una vulnerabilidad crítica descubierta seis meses después. Si no hay un equipo activo manteniendo el código, esa vulnerabilidad no se parchea. La app sigue operando con la vulnerabilidad hasta que alguien — un auditor, un atacante — la encuentra.
Los incentivos están mal alineados
El contratista tiene incentivo para entregar la app funcionando, dentro del plazo y dentro del presupuesto. La seguridad no suele ser un criterio de aceptación con el mismo peso que la funcionalidad. Si la app hace lo que el requerimiento dice que debe hacer, el contratista cobra y se va. Si la app tiene una inyección SQL que permite acceder a la base de datos, pero el requerimiento no decía «no debe tener inyecciones SQL,» el contratista no tiene responsabilidad contractual.
No hay revisión de código independiente
En la mayoría de los proyectos de desarrollo gubernamental que he visto — y he participado como perito en litigios que involucran software gubernamental –, no hay una revisión de seguridad independiente del código antes de la entrega. No hay pentesting. No hay auditoría de código. No hay nada que verifique que el código que el contratista entregó cumple con estándares de seguridad. La aceptación se basa en pruebas funcionales: «la app hace lo que dijimos que debía hacer.» No en pruebas de seguridad: «la app es segura.»
La rotación de personal del contratista
Los desarrolladores que escriben el código de las apps del gobierno son empleados del contratista, no del gobierno. Cuando el contrato termina, esos desarrolladores pasan a otro proyecto, con otro cliente, en otra industria. Y se llevan consigo el conocimiento del código, la arquitectura y, potencialmente, las credenciales de acceso a los sistemas.
He visto — en peritajes que Duriva ha realizado en litigios que involucran software gubernamental — casos donde exempleados de contratistas conservaban acceso a repositorios de código fuente de aplicaciones gubernamentales meses después de que el contrato había terminado. No porque hubieran hackeado nada, sino porque nadie les revocó los accesos. Nadie sabía que tenían acceso. Nadie llevaba un inventario de quién tenía acceso a qué.
La responsabilidad compartida: gobierno, contratistas y ciudadanos
Este problema no es culpa de un solo actor. Es un fallo sistémico con responsabilidades compartidas.
El gobierno es responsable porque no establece estándares de ciberseguridad obligatorios para el desarrollo de aplicaciones. No exige pentesting antes del despliegue. No exige revisiones de código independientes. No exige auditorías de seguridad periódicas. No tiene equipos internos con la capacidad técnica para verificar que lo que el contratista entregó es seguro. Y no tiene un programa de divulgación de vulnerabilidades que permita a investigadores externos reportar hallazgos de forma segura.
Los contratistas son responsables porque entregan software con vulnerabilidades básicas que no deberían existir en 2026. Transmisión en HTTP plano. Tokens predecibles. Almacenamiento sin cifrar. Logs de depuración en producción. Estos no son errores sofisticados. Son errores básicos que cualquier desarrollador con formación mínima en seguridad debería detectar y corregir. Su existencia indica que los contratistas no tienen procesos de desarrollo seguro (Secure SDLC), no hacen revisiones de seguridad del código y no priorizan la protección de los datos de los usuarios.
Los ciudadanos tenemos responsabilidad limitada pero no nula. Debemos exigir que nuestros datos estén protegidos. Debemos reportar vulnerabilidades cuando las encontremos — a través de canales seguros, con divulgación responsable. Y debemos tener conciencia de que las apps gubernamentales, por ser gubernamentales, no son automáticamente seguras. El escudo nacional en el icono de la app no es garantía de seguridad. Es un icono.
Divulgación responsable: lo que hicimos con los hallazgos
Duriva practica la divulgación responsable. Siempre lo ha hecho. Siempre lo hará.
Los hallazgos de esta auditoría fueron reportados a las dependencias correspondientes a través de los canales disponibles. Se les proporcionó un reporte técnico detallado con la descripción de cada vulnerabilidad, la evidencia de su existencia, la clasificación de severidad según CVSS (Common Vulnerability Scoring System) y las recomendaciones de remediación.
Voy a ser honesto sobre la experiencia de divulgación responsable con gobierno en México: es frustrante.
Las dependencias gubernamentales no tienen, en su mayoría, un canal establecido para recibir reportes de vulnerabilidades. No tienen un equipo de seguridad de aplicaciones que pueda evaluar el reporte. No tienen un proceso de respuesta a incidentes que incluya la evaluación de reportes externos. En la práctica, lo que hicimos fue contactar por múltiples vías hasta encontrar a alguien que entendiera de qué estábamos hablando.
En algunos casos, obtuvimos respuesta. En otros, silencio. En ningún caso obtuvimos confirmación formal de que las vulnerabilidades habían sido remediadas. Algunos hallazgos que reportamos hace meses siguen presentes hoy. Otros parecen haber sido corregidos — lo verificamos de forma periódica, de la misma manera pasiva en que los encontramos originalmente.
La falta de un programa de divulgación de vulnerabilidades (VDP — Vulnerability Disclosure Program) en las dependencias gubernamentales mexicanas es un problema serio. En Estados Unidos, CISA exige que las agencias federales tengan un VDP. Es una directiva vinculante (BOD 20-01). Cualquier persona que encuentre una vulnerabilidad en un sistema del gobierno de Estados Unidos tiene un canal oficial, seguro y protegido legalmente para reportarla. En México, eso no existe. Y eso significa que los investigadores que encuentran vulnerabilidades en sistemas gubernamentales tienen tres opciones: reportarlas y arriesgarse a ser ignorados (o peor, a ser denunciados), publicarlas sin reportarlas (irresponsable), o callarse y dejar que las vulnerabilidades persistan indefinidamente.
Ninguna de esas opciones es buena. México necesita un VDP federal. Ya.
Lo que debería hacerse
Estándares de desarrollo seguro obligatorios. Toda aplicación gubernamental — web o móvil — debe desarrollarse siguiendo un ciclo de vida de desarrollo seguro (Secure SDLC). Esto incluye: análisis de requisitos de seguridad, diseño seguro, codificación segura, pruebas de seguridad estáticas y dinámicas antes del despliegue, y mantenimiento de seguridad continuo después del despliegue. Estos requisitos deben estar en los contratos con los contratistas. No como sugerencia. Como obligación contractual verificable.
Auditoría de seguridad independiente antes del despliegue. Ninguna app gubernamental debería desplegarse sin pasar por una auditoría de seguridad realizada por un tercero independiente del contratista que la desarrolló. Pentesting. Revisión de código. Análisis de configuración. Evaluación de la gestión de datos. Si la app no pasa la auditoría, no se despliega.
Programa de divulgación de vulnerabilidades federal. Un canal oficial, protegido legalmente, administrado por CERT-MX o una entidad equivalente, para que investigadores de seguridad puedan reportar vulnerabilidades en sistemas gubernamentales sin riesgo legal. Con compromisos de respuesta en tiempos definidos. Con transparencia sobre el estado de la remediación.
Equipos internos de seguridad de aplicaciones. Las dependencias que manejan datos sensibles de ciudadanos — SAT, IMSS, ISSSTE, SEP, INE, Secretaría de Salud — deben tener equipos internos con la capacidad técnica de evaluar la seguridad de las aplicaciones que operan. No pueden depender exclusivamente del contratista para la seguridad del producto que el contratista les entregó. Es como comprar una cerradura y confiar en que funciona solo porque el cerrajero dijo que funciona. Necesitas que alguien más la pruebe.
Gestión de accesos de contratistas. Cada acceso otorgado a un contratista — a repositorios de código, a servidores, a bases de datos, a ambientes de desarrollo, a cualquier sistema — debe estar inventariado y debe ser revocado formalmente al terminar el contrato. No al día siguiente. No «cuando nos acordemos.» Al momento de la terminación del contrato. Con verificación independiente de que la revocación fue efectiva.
Lo que necesita saber cada persona que lee esto
Contribuyente que usa la app del SAT: usa la app con precaución. No la uses en redes WiFi públicas. Cierra sesión manualmente cada vez que termines de usarla — no solo cierres la app, cierra la sesión dentro de la app. Usa una contraseña única para tu cuenta del SAT que no uses en ningún otro servicio. Activa la autenticación de dos factores si está disponible. Y revisa periódicamente tus datos fiscales para detectar actividad no autorizada.
Derechohabiente que usa la app del IMSS: las mismas precauciones aplican. Tu historial médico es información sensible. No debería estar accesible en un caché sin cifrar en tu teléfono. Pero puede estarlo. Mantén tu teléfono actualizado con la última versión del sistema operativo, usa bloqueo de pantalla con biometría o PIN robusto y no prestes tu teléfono.
Desarrollador que trabaja en proyectos gubernamentales: implementa HTTPS en todas las comunicaciones, sin excepciones. Usa certificate pinning. Almacena tokens y datos sensibles en Keychain/KeyStore. Implementa expiración de sesión en tiempos razonables. Valida la autorización en cada endpoint de la API. Elimina logs de depuración antes de publicar. Haz estas cosas no porque el contrato te lo exija — probablemente no lo exige — sino porque los datos de millones de mexicanos dependen de tu código.
Funcionario de gobierno responsable de tecnología: las apps que tu dependencia opera son la interfaz entre el gobierno y millones de ciudadanos. La seguridad de esas apps es la seguridad de los datos de esos ciudadanos. Y la seguridad no se logra exigiendo que el contratista firme una cláusula de confidencialidad. Se logra con estándares técnicos verificables, auditorías independientes y equipos internos con la capacidad de evaluar lo que el contratista entrega.
Usé las apps del gobierno un mes. Lo que encontré no es sofisticado. No son vulnerabilidades zero-day que requieran equipos de inteligencia para descubrir. Son errores básicos. Errores de primer semestre de seguridad informática. Errores que cualquier empresa privada seria — un banco, una fintech, un comercio electrónico — detectaría y corregiría antes de lanzar al público.
Pero las apps del gobierno no pasan por los mismos filtros que las apps del sector privado. No tienen el mismo nivel de escrutinio. No tienen el mismo nivel de exigencia. Y no tienen el mismo nivel de consecuencias cuando fallan.
Cuando un banco tiene una vulnerabilidad en su app, la aseguradora lo presiona, el regulador lo sanciona, los clientes se van. Hay consecuencias de mercado. Cuando una app del gobierno tiene una vulnerabilidad, no pasa nada. El ciudadano no puede «irse» a otro SAT. No puede «cambiar» de IMSS. Es usuario cautivo de un servicio que no eligió y que no puede dejar.
Y eso, precisamente, es lo que debería obligar al gobierno a ser más exigente con la seguridad de sus apps, no menos. Porque el ciudadano no tiene opción. Y quien no tiene opción merece, como mínimo, que sus datos estén protegidos con los estándares que la tecnología actual permite.
Llevo 17 años auditando sistemas. He auditado bancos. He auditado corporativos. He auditado hospitales. He auditado despachos de abogados. He auditado a todos. Y los hallazgos en las apps del gobierno no son los peores que he visto — he visto cosas peores en empresas privadas. Pero son los más preocupantes. Porque afectan a más personas. Porque los datos son más sensibles. Y porque el ciudadano que confía en ellas no tiene alternativa.
Esa confianza obligatoria debería venir con una garantía de seguridad obligatoria. Hoy, esa garantía no existe.