El experimento: $1,500 probando si LLMs pueden hackear una app vulnerable
Un investigador de seguridad construyó una aplicación React Native deliberadamente vulnerable y gastó $1,500 dólares probando 15+ modelos de IA para ver cuáles podían explotarla. Los resultados revelan diferencias dramáticas en capacidad ofensiva y costo por exploit exitoso.
La app simulaba un sistema de reseñas de libros con backend en Python/FastAPI y Firebase como capa de datos. El objetivo: encontrar un flag oculto en reseñas privadas de usuarios mediante Broken Access Control, la misma vulnerabilidad que afecta comúnmente a startups que usan Firebase o Supabase sin configuración adecuada.
Ranking de modelos: quién hackeó mejor y a qué costo
Los resultados del testing (10 intentos por modelo) muestran una brecha significativa entre capacidades:
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad- GPT-5.5: 7/10 exploits exitosos, $9.46 por solve
- DeepSeek V4 Pro: 3/10, $0.62 por solve (el más económico)
- Claude Opus 4.8: 2/10, $16.15 por solve
- Claude Sonnet 4.6: 2/10, $45.75 por solve (el más costoso)
- Gemini, Grok, Qwen, GLM, MiniMax: 0-1 solves cada uno
Un patrón notable: los modelos chinos (DeepSeek, GLM, Qwen) mostraron mayor disposición a atacar la base de datos directamente, mientras que los modelos occidentales tuvieron más "bloqueos morales" durante el proceso.
La vulnerabilidad: Firebase mal configurado es la puerta abierta
El exploit aprovechó un error común en startups: el archivo google-services.json dentro de la app móvil contenía credenciales de Firebase que permitían registrarse como usuario y leer directamente la base de datos Firestore.
Esta es exactamente la categoría de vulnerabilidad Broken Access Control / Missing Object-Level Authorization que aparece repetidamente en auditorías de seguridad a startups hispanas. La API en sí era segura, pero la capa de datos tenía permisos demasiado abiertos.
Según fuentes de seguridad como Proofpoint y SentinelOne (2025-2026), los controles de acceso defectuosos siguen siendo uno de los vectores más frecuentes en aplicaciones SaaS, especialmente cuando se prioriza velocidad de desarrollo sobre seguridad.
Costos ocultos del agentic AI para security testing
El experimento reveló problemas prácticos que todo founder debe considerar:
- Preempción de infraestructura: Usar Modal para correr agentes causó pérdida de ejecuciones cuando los contenedores se preemptaban
- API outages constantes: MiniMax y GLM tuvieron interrupciones frecuentes que invalidaron pruebas
- El harness fue lo más difícil: Construir el sistema de testing automático consumió más tiempo que el análisis en sí
Para founders que consideran usar IA para red teaming propio: el costo real no es solo el de los tokens, sino la infraestructura, la repetición de pruebas fallidas y el tiempo de ingeniería para montar el pipeline.
¿Qué significa esto para tu startup?
Si tu startup usa Firebase, Supabase o cualquier backend-as-a-service, este experimento tiene implicaciones directas:
1. Audita tus reglas de acceso HOY
- Revisa las reglas de Firestore/Realtime Database con política deny by default
- Verifica que no haya endpoints públicos que expongan datos de usuarios
- Implementa validación a nivel de objeto, no solo a nivel de usuario
2. No confíes en que "la API es segura"
Como mostró el experimento, puedes tener una API bien protegida pero una capa de datos vulnerable. Los atacantes (y los LLMs) buscan el camino de menor resistencia, no el más obvio.
3. Si usas IA para security testing, presupuesta 3-5x más
El costo por solve exitoso varía dramáticamente. GPT-5.5 fue el más efectivo pero no el más barato. DeepSeek V4 Pro resolvió menos casos pero a 1/15 del costo. Para testing continuo, la relación costo-efectividad puede importar más que el solve rate máximo.
4. Considera un pentest tradicional complementario
Los LLMs son útiles para encontrar vulnerabilidades comunes rápidamente, pero tienen limitaciones. Las fuentes de seguridad recomiendan pentesting humano trimestral + red teaming mensual con IA para cobertura completa.
Lecciones para founders que implementan IA
El autor del experimento ofrece el ZIP del challenge para replicación y realiza auditorías de seguridad. Pero más allá de eso, hay tres lecciones accionables:
- Los modelos occidentales tienen más guardrails: Esto puede ser bueno (no exfiltran datos) o malo (no completan tareas ofensivas legítimas). Evalúa según tu caso de uso.
- La infraestructura importa tanto como el modelo: Outages y preempciones pueden invalidar semanas de testing. Usa proveedores estables para producción.
- Documenta todo: El harness de testing fue lo más complejo. Invierte tiempo en hacerlo reproducible y monitoreado.
Fuentes
- https://kasra.blog/blog/i-spent-1500-seeing-if-llms-could-hack-my-app/ (fuente original)
- https://www.proofpoint.com/es/blog/dspm/llm-security-risks-best-practices-solutions (seguridad LLM)
- https://www.sentinelone.com/es/cybersecurity-101/data-and-ai/llm-security/ (mejores prácticas IA)
- https://pentraze.com/es/services/ai-llm-pentesting/ (AI pentesting)
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad
