El Breach de 700Credit: Cómo una API Desprotegida Filtró Datos de 6 Millones de Personas
En octubre de 2025, una empresa llamada 700Credit descubrió algo aterrador: durante 5 meses, alguien había estado extrayendo datos de casi 6 millones de personas. Nombres, direcciones, fechas de nacimiento y números de seguro social (SSN) — todo filtrado.
¿Lo peor? No fue un ataque sofisticado. No hubo hackers de película rompiendo firewalls. Fue algo mucho más simple: una API sin las protecciones básicas.
Si tu startup tiene una API (y probablemente la tiene), este caso te interesa.
Primero: ¿Qué es una API y Por Qué Importa?
Antes de entrar en el caso, expliquemos qué es una API de forma simple.
Una API es como un mesero en un restaurante. Tú (el cliente) le dices al mesero qué quieres. El mesero va a la cocina, pide tu orden, y te trae la comida. Tú nunca entras a la cocina directamente.
En el mundo digital:
- Tú = una aplicación o usuario
- El mesero = la API
- La cocina = la base de datos con información sensible
La API es el intermediario que recibe peticiones y devuelve datos. El problema es cuando ese "mesero" no verifica quién está pidiendo qué, ni cuántas veces.
¿Qué es 700Credit y Qué Pasó?
700Credit es una empresa fintech que verifica el crédito de personas que quieren comprar autos. Cuando alguien pide financiamiento en un concesionario, 700Credit revisa su historial crediticio. Trabajan con unos 18,000 concesionarios en Estados Unidos.
La Línea de Tiempo del Desastre
- Julio 2025: Atacantes comprometen a un socio de 700Credit (una empresa que se conectaba a su sistema)
- Mayo-Octubre 2025: Usando credenciales robadas, los atacantes consultan la API millones de veces
- 25 de Octubre 2025: 700Credit finalmente detecta actividad sospechosa
- Resultado: 5,836,521 personas con sus datos expuestos
Durante 5 meses, nadie notó nada. Los atacantes simplemente preguntaban "dame los datos del cliente 1", "dame los datos del cliente 2", "dame los datos del cliente 3"... millones de veces.
Las 3 Fallas Que Permitieron el Ataque
Falla 1: La API No Verificaba "¿Este Dato Es Tuyo?"
Imagina un edificio de apartamentos donde cada residente tiene una llave electrónica. La llave te deja entrar al edificio, pero debería solo abrir tu apartamento.
En 700Credit, la "llave" te dejaba entrar al edificio... y abrir cualquier apartamento. Si eras un socio autorizado, podías pedir datos de cualquier cliente, no solo los que te correspondían.
El director de 700Credit lo admitió:
"No estábamos validando el ID del consumidor contra el solicitante original."
En términos simples: Si yo soy el concesionario A y consulté el crédito de Juan, solo debería poder ver los datos de Juan. Pero la API me dejaba ver también los datos de María, Pedro, y los otros 6 millones de personas.
Falla 2: Sin Límite de Peticiones (El Buffet Sin Control)
Piensa en un restaurante buffet que cobra $20 por persona. La gente normalmente come 2-3 platos. Un día llega alguien con 50 tuppers y empieza a empacar comida. Como no hay regla de "máximo 3 platos", técnicamente no viola nada.
La API de 700Credit era ese buffet. Los atacantes hicieron (en palabras de la empresa) "millones y millones" de peticiones. No había límite que dijera "oye, este socio normalmente hace 100 consultas al día, ¿por qué está haciendo 100,000?".
Rate limiting es ponerle un límite al buffet: "máximo 5 platos por persona". Es básico, pero 700Credit no lo tenía.
Falla 3: Credenciales Que Nunca Expiraban
Cuando le das una copia de las llaves de tu casa a alguien, asumes cierto riesgo. Si esa persona pierde las llaves, quien las encuentre puede entrar.
La solución obvia: cambiar la cerradura periódicamente.
Los "tokens" de acceso a la API de 700Credit eran como llaves que nunca se cambiaban. El socio comprometido tenía credenciales válidas, y esas credenciales siguieron funcionando durante meses después del robo.
Si los tokens expiraran cada pocas horas y se renovaran automáticamente, el ataque se habría detenido mucho antes.
¿Por Qué No Lo Detectaron en 5 Meses?
Porque los atacantes usaban credenciales legítimas. Desde el punto de vista del sistema, era un socio autorizado haciendo consultas. No hubo alarmas porque:
- Las peticiones venían de una fuente "confiable"
- No había alertas por volumen inusual
- Solo hacían auditorías periódicas, no monitoreo continuo
- El socio comprometido nunca avisó que había sido atacado
Es como si el ladrón entrara con una copia de la llave real. Las cámaras lo graban, pero nadie revisa las grabaciones porque "tiene llave, debe ser alguien autorizado".
El Costo: Más Allá de los Números
Para las Víctimas
- 5.8 millones de personas con su SSN expuesto
- Riesgo de robo de identidad de por vida
- El SSN no se puede cambiar como una contraseña
Para 700Credit
- Múltiples demandas colectivas en curso
- 12 meses de monitoreo de crédito gratuito para afectados (costo millonario)
- Investigaciones del FBI y fiscales estatales
- Daño reputacional con sus 18,000 clientes concesionarios
El Dato Que Duele
Según IBM, el costo promedio de una brecha de datos en Estados Unidos es de $10.22 millones de dólares. Y eso es el promedio — un breach con SSNs de 6 millones de personas será mucho mayor.
Lecciones Para Tu Startup
Este breach no requirió hackers geniales ni herramientas sofisticadas. Solo requirió:
- Credenciales robadas de un tercero
- Una API que no verificaba permisos correctamente
- Ausencia de límites en las peticiones
- Nadie mirando los logs
Pregúntate sobre tu propia aplicación:
- Si alguien roba las credenciales de un usuario, ¿puede acceder a datos de OTROS usuarios?
- ¿Tienes límites de cuántas peticiones puede hacer alguien por minuto/hora?
- ¿Tus tokens de acceso expiran? ¿Cada cuánto?
- ¿Alguien revisa si hay patrones de uso anormales?
- Si un socio o integración tuya fuera comprometida hoy, ¿cuánto tardarías en enterarte?
Checklist Básico de Protección Para APIs
- Verificar permisos por recurso: Cada petición debe validar "¿este usuario tiene derecho a ver ESTE dato específico?"
- Implementar rate limiting: Limitar peticiones por minuto/hora según uso normal
- Tokens con expiración corta: Que las credenciales expiren cada pocas horas, no cada meses
- Monitoreo de anomalías: Alertas cuando alguien hace 10x más peticiones de lo normal
- Logs de acceso a datos sensibles: Registrar quién accede a qué y cuándo
- Contratos con terceros: Cláusulas que obliguen a notificar breaches en 24 horas
El Costo de Prevenir vs. El Costo de Un Breach
| Prevención | Costo |
|---|---|
| Pentest de APIs | $5,000 - $15,000 |
| Implementar rate limiting | Horas de desarrollo |
| Sistema de monitoreo | $500 - $2,000/mes |
| Total aproximado | < $30,000 |
| Breach | Costo |
|---|---|
| Promedio en EE.UU. | $10,220,000 |
| Demandas colectivas | Millones adicionales |
| Pérdida de clientes | Incalculable |
| Total aproximado | > $10,000,000 |
La matemática es clara.
Conclusión
El breach de 700Credit no fue obra de hackers de élite. Fue el resultado de no implementar controles básicos que cualquier startup puede (y debe) tener.
Las APIs son la columna vertebral de las aplicaciones modernas. Si la tuya maneja datos sensibles — información de usuarios, datos financieros, información personal — protegerla no es opcional.
La buena noticia: estos problemas son detectables antes de que alguien los explote. Un pentest de APIs revisa exactamente estos escenarios: ¿puedo acceder a datos que no me corresponden? ¿Puedo hacer peticiones masivas sin que nadie me detenga? ¿Los tokens son seguros?
Mejor descubrirlo en una auditoría controlada que en las noticias.
Referencias
- 700Credit Data Breach Impacts 5.8 Million Individuals - SecurityWeek
- 700Credit Breach Analysis - Bright Defense
- Cost of a Data Breach 2025 - IBM
- Attorney General Nessel Statement - Michigan.gov
Sobre el Autor
Juan Camilo Palacio Alvarez es el fundador de Pentacode, consultora especializada en pentesting y desarrollo seguro para startups.