Casi dos tercios de las apps de iPhone con IA exponen claves de pago y pueden generar facturas millonarias

Un estudio reciente de investigadores de Wake Forest University sacudió la idea de que las apps de iPhone que integran asistentes de lenguaje grande (LLMs) son seguras por defecto: al analizar 444 aplicaciones, hallaron que 282 —casi dos tercios— expusieron de algún modo el acceso de pago a los modelos en su tráfico de red. Esto no es un hallazgo académico aislado, sino una advertencia práctica: claves en texto plano, tokens reutilizables o servidores intermedios que aceptan cualquier petición permiten a terceros ejecutar modelos con la cuenta del desarrollador y que el dueño de la clave reciba la factura.

Lo que hace particularmente inquietante este problema es la simplicidad del ataque. El equipo usó una herramienta propia, LLMKeyLens, para observar el tráfico saliente y extraer credenciales sin necesidad de jailbreak ni ingeniería inversa compleja: bastó con capturar paquetes y leer lo que la app enviaba. El vector de explotación es puro diseño inseguro: incrustar secretos en el cliente móvil o no validar quién llama al backend expone un acceso pagado y revocable por defecto.

Los hallazgos muestran tres patrones recurrentes. Un grupo enviaba la clave en texto claro y la misma petición a veces incluía el system prompt oculto que define la personalidad del asistente; otro grupo confiaba en servidores sin autenticación que actuaban como retransmisores abiertos; y el tercero entregaba tokens temporales que, aun así, se filtraban con el tráfico y a menudo seguían siendo válidos. En varios casos los tokens nunca caducaban con sentido práctico —uno vencía en 2125— o persistían mucho tiempo después de lo esperado.

Las consecuencias van más allá de un apuro técnico: existe un riesgo directo de abuso económico, conocido como LLMjacking, donde atacantes usan credenciales robadas para consumir API y generar facturas millonarias en pocos días. También hay daño reputacional y de privacidad cuando prompts y conversaciones se filtran, lo que puede afectar a usuarios que usen apps de salud, productividad o finanzas.

Para desarrolladores la receta es vieja pero poco aplicada: nunca almacenar claves secretas en el cliente. En su lugar, las llamadas a proveedores de modelos deben pasar por un servidor propio que autentique a los usuarios, aplique límites, registre actividad y pueda rotar o revocar credenciales en cuanto detecte uso anómalo. Además, conviene emitir tokens con el menor alcance y vida posible, y programar rotación automática. Documentos de mejores prácticas para gestión de credenciales y seguridad de APIs como los de OWASP y de los mismos proveedores son recursos útiles: OWASP API Security Project y las recomendaciones de seguridad de OpenAI en la documentación oficial.

Más allá de la arquitectura, hay medidas operativas cruciales: habilitar alertas de uso inusual en el panel del proveedor del modelo, fijar presupuestos y límites de gasto, registrar y monitorizar llamadas por clave y por origen, y automatizar la revocación de claves comprometidas. Los proveedores en la nube también ofrecen controles para restringir el uso de claves por dirección IP o por referer; aprovechar esas políticas reduce la superficie de ataque. Google Cloud y otros proveedores documentan prácticas concretas para proteger claves de API en sus guías.

Los usuarios finales también pueden actuar: preferir apps de desarrolladores que publiquen políticas claras sobre cómo usan y protegen las APIs de IA, revisar valoraciones y reputación, y prestar atención a permisos y comportamiento anómalo. Si eres desarrollador afectado, considera como prioridad rotar claves exposadas, informar a usuarios si hubo riesgo de fuga de datos y publicar un plan público de mitigación; la transparencia es clave para recuperar confianza.

Las plataformas tienen un papel crítico. Apple podría ampliar los controles del proceso de revisión y ofrecer escaneos automatizados que detecten patrones de envío de claves en tráfico o binarios, además de exigir prácticas mínimas de seguridad para integraciones de IA. Por su parte, los proveedores de modelos deberían marcar claramente en su documentación y en sus consolas cuando una clave se emite para uso cliente y restringir capacidades peligrosas por defecto, además de alertar sobre usos masivos e inusuales.

Este problema no es nuevo en esencia: auditorías previas en Android y auditorías más amplias ya mostraron que desarrolladores tienden a no revocar claves ni a poner controles. La diferencia ahora es el coste por abuso: cada token utilizado por un LLM representa gasto real. La lección práctica es directa: seguridad y diseño deben ir por delante de la integración rápida, porque una credencial filtrada no es sólo una vulnerabilidad técnica, es una línea que conecta facturación, privacidad y confianza.

Si eres responsable técnico en una app móvil, actúa hoy: elimina secretos del cliente, rediseña el flujo para pasar por un backend autenticado, implementa monitorización y alertas en el proveedor y pon en práctica la rotación y revocación de claves. La industria tiene que cambiar la inercia de "funciona ahora, luego parcheamos" hacia una disciplina donde proteger el acceso a los modelos sea parte del ciclo de desarrollo. Sin ese cambio, seguiremos viendo investigaciones que vuelven a mostrar lo mismo: puertas abiertas donde no deberían existir.