Es cuando una organización pierde el control sobre qué APIs tiene expuestas, permitiendo que versiones antiguas, endpoints deprecados o APIs de prueba permanezcan activas y accesibles, expandiendo la superficie de ataque.
El Problema Fundamental
"Lo que no conoces, no puedes proteger" - Las APIs olvidadas se convierten en puertas traseras no monitoreadas.
Escenarios
API Versioning Descontrolado
c
# API actual que todos conocen y protegen:
https://api.company.com/v1/ ✅ Mantenido y seguro
# API antigua que OLVIDARON:
https://api.company.com/v0/ ❌ Deprecada pero ACTIVAc
// Versión v1 - Protegida y mantenida
GET /api/v1/customers/active
Requiere: Authentication Bearer Token
Respuesta: Datos mínimos necesarios
// Versión v0 - OLVIDADA y sin protección
GET /api/v0/customers/deleted
NO requiere autenticación
Respuesta: Datos sensibles completos + password hashesPuede tener datos expuestos:
c
{
"deletedCustomers": [
{
"id": "123",
"name": "Juan Pérez",
"email": "juan@email.com",
"phone": "+123456789",
"birthDate": "1985-03-15",
"passwordHash": "$2a$10$hashed_password_here..." // ¡CRÍTICO!
}
]
}APIs de Desarrollo en Producción
c
# Desarrollo - debería estar interno
http://api-dev.company.com/swagger
http://staging-api.company.com/graphql
# Pero terminan expuestos públicamente
# Con datos reales de prueba o desarrolloEndpoints Deprecados No Eliminados
c
// Endpoint antiguo de reportes (2018)
GET /api/legacy/reports/financial
// Nuevo endpoint (2023)
GET /api/v2/reports/financial
// El viejo sigue activo con vulnerabilidades conocidasMicroservicios Huérfanos
c
# Servicios que nadie recuerda:
- notification-service-v1 (sin updates desde 2020)
- legacy-auth-service (usaba MD5 para passwords)
- reporting-api-old (sin autenticación)
- internal-tools-api (acceso público)APIs de Third-Party Abandonadas
c
# API de integración con partner que quebró
https://api.integration-dead-company.com/v1/
# Pero sigue respondiendo con datos de nuestra empresa
# Y sin mantenimiento de seguridad