Tema 15
Las APIs se convirtieron en el núcleo de muchas aplicaciones modernas, pero también ampliaron la superficie de ataque. Cuando un endpoint acepta demasiada entrada, devuelve más datos de los necesarios o confía demasiado en el cliente, el atacante encuentra una interfaz poderosa, automatizable y muchas veces más silenciosa que la web tradicional.
Las APIs son hoy la columna vertebral de aplicaciones web, móviles, integraciones con terceros, paneles administrativos, microservicios y automatizaciones internas. Desde el punto de vista del negocio, esto trae flexibilidad y escalabilidad. Desde seguridad, también trae una realidad clara: muchas decisiones sensibles ya no pasan por la interfaz visual, sino por endpoints capaces de aceptar, procesar y devolver información estructurada a gran velocidad.
Una API insegura puede exponer más datos de los necesarios, aceptar campos que nunca debió aceptar, permitir acceso indebido a objetos, facilitar automatización masiva o dejar visible una lógica de negocio que la interfaz tradicional ocultaba parcialmente.
En este tema nos centraremos en tres ejes complementarios: APIs inseguras, validación de entradas y exposición excesiva de datos, porque en la práctica suelen combinarse y potenciarse entre sí.
En una aplicación web clásica, parte de la lógica visible está mediada por formularios, botones y navegación. En una API, el cliente interactúa más directamente con el backend. Eso no hace a la API insegura por definición, pero sí cambia la relación entre usuario y superficie de ataque.
Las APIs suelen ser:
Una API se vuelve insegura cuando permite más de lo necesario, valida menos de lo debido o expone datos y acciones con exceso de confianza hacia el cliente.
Esto puede verse en:
Validar entradas en una API no significa solo revisar si el JSON es sintácticamente correcto o si el correo tiene una arroba. La validación real debe responder también si el dato tiene sentido dentro del negocio, del rol del usuario y del estado del sistema.
Por eso conviene pensar tres niveles:
Uno de los errores más comunes en APIs es aceptar objetos completos del cliente y mapearlos casi automáticamente a entidades internas. Esto puede permitir que el atacante envíe campos que el frontend normal nunca mostraría, pero que el backend igual procesa.
Ese patrón abre problemas como:
Este tipo de riesgo suele vincularse al concepto de mass assignment.
No toda brecha ocurre porque el atacante "rompe" algo. A veces la API simplemente devuelve demasiado. Campos internos, estados administrativos, identificadores, datos de otros usuarios o información sensible pueden quedar expuestos por respuestas innecesariamente ricas.
Problemas típicos:
Un error recurrente es pensar que si el frontend no usa cierto campo o no muestra cierto dato, entonces ya está protegido. En una API eso es especialmente falso. El cliente puede ser manipulado, reemplazado o reimplementado por completo por el atacante.
Por eso la API debe ser segura por sí misma. Debe aceptar solo lo necesario y responder solo con lo permitido, sin confiar en que otro cliente "hará lo correcto" con esos datos.
Las APIs suelen trabajar intensamente con objetos identificables: usuarios, pedidos, facturas, documentos, tickets, mensajes, recursos de negocio. Si la autorización por objeto está mal diseñada, la API se vuelve una vía ideal para exfiltrar o modificar información ajena.
Preguntas críticas:
Otra fuente de riesgo en APIs son los endpoints que permiten operar sobre muchos objetos o estados con muy poca fricción. Si no existen límites, segmentación o controles contextuales, el abuso puede escalar rápidamente.
Ejemplos:
La estructura predecible de una API facilita automatización. Si los endpoints aceptan demasiada entrada o responden con información útil para el atacante, este puede iterar, enumerar objetos, exfiltrar datos o probar combinaciones a gran velocidad.
Por eso la seguridad de API no puede limitarse a validar que "cada request parece correcta". También debe considerar frecuencia, volumen, patrones de abuso y comportamiento agregado.
Definir un esquema JSON o tipado ayuda mucho, pero no resuelve por sí solo los problemas de seguridad. Un payload puede cumplir perfectamente la estructura esperada y aun así ser abusivo o improcedente según el negocio.
Ejemplo conceptual:
La seguridad necesita validación de negocio, no solo de formato.
Muchas organizaciones mantienen varias versiones de una API por compatibilidad. Esto puede introducir deuda de seguridad si endpoints antiguos, menos restringidos o mal documentados siguen disponibles sin revisión suficiente.
El problema no es solo técnico, sino de gobernanza: cada versión activa amplía la superficie que debe protegerse, monitorearse y auditarse.
Una práctica muy útil es diseñar respuestas pensadas para el caso de uso real en lugar de exponer entidades completas. Esto reduce exposición accidental, simplifica auditoría y limita impacto si un endpoint queda accesible más allá de lo previsto.
El principio puede resumirse así: devolver solo lo que ese cliente, en ese contexto, realmente necesita.
Del mismo modo, conviene que cada endpoint acepte solo los campos estrictamente necesarios. Cuanto más abierto sea el contrato, más difícil será razonar sobre seguridad y más oportunidades habrá para abuso.
Un contrato explícito ayuda a:
Las APIs no solo deben ser correctas por request, sino también resistentes a abuso sostenido. Rate limiting, cuotas, segmentación por rol y control de patrones ayudan a contener scraping, enumeración y exfiltración masiva.
Esto no reemplaza la autorización ni la validación, pero sí limita el poder operativo del atacante cuando encuentra una superficie utilizable.
Las APIs inseguras se conectan con varias categorías del curso.
Esto explica por qué la seguridad de APIs debe tratarse como disciplina propia dentro de la seguridad web moderna.
Las APIs inseguras muestran que la modernización tecnológica no elimina los problemas clásicos de seguridad; muchas veces los vuelve más directos, más veloces y más fáciles de automatizar. Cuando una API acepta demasiado o devuelve demasiado, el atacante obtiene una interfaz muy poderosa para explorar, abusar y exfiltrar.
En el próximo tema estudiaremos pruebas de seguridad web, herramientas y metodología básica, para integrar una mirada más sistemática sobre cómo descubrir y validar las vulnerabilidades vistas a lo largo del curso.