Shadow API
Una shadow API es una interfaz viva y alcanzable pero ausente del inventario que la organización defiende: sin documentar, olvidada tras una migración, o funcionando todavía desde una versión que se suponía retirada. Está autenticada y monitorizada al nivel que rigiera el día en que se construyó, que suele ser ninguno.
Se acumulan de formas previsibles. Un endpoint versionado sigue alcanzable después de que el cliente pase a otro. Una máquina de preproducción se queda resolviendo. Un servicio interno se expone a un socio a través de una pasarela y nunca se añade al registro. Una aplicación móvil llama a un backend cuya existencia el equipo web desconoce. En cada caso, las políticas de la pasarela, los límites de tasa y el registro que protegen el parque documentado sencillamente no se aplican.
En un encargo externo son de las primeras cosas que buscamos, y las fuentes son poco vistosas: registros de transparencia de certificados, enumeración de DNS, paquetes de JavaScript que nombran máquinas a las que el sitio no llama nunca, tráfico de aplicaciones móviles y documentos de especificación que quedaron publicados en rutas convencionales. Una versión antigua de un endpoint responde con frecuencia con una autenticación más débil que su sustituta, y eso es lo que hace que el hallazgo importe.
El hallazgo se escribe contra el proceso de inventario y no contra la máquina concreta, porque el endpoint que encontramos es la evidencia de un hueco y no el hueco en sí. La corrección duradera es que toda interfaz publicada la descubra el attack surface management y se concilie contra el inventario de activos, tratando la retirada como un paso más del despliegue. Aquí es donde se gana su sitio el pentesting de API que arranca de lo que podemos encontrar y no de la documentación.