Tema 2
La seguridad de una API empieza mucho antes de validar tokens o limitar solicitudes. Empieza en su arquitectura: qué recursos expone, cómo se nombran los endpoints, qué operaciones se permiten, cómo se relacionan los componentes y qué decisiones de diseño amplían o reducen la superficie de ataque.
Una API REST no es únicamente un conjunto de URLs. Es una arquitectura de interacción entre clientes, recursos, reglas de negocio, autenticación, almacenamiento y servicios auxiliares. Cada decisión sobre cómo se modela esa interacción tiene consecuencias directas sobre la seguridad.
Una arquitectura desordenada suele producir endpoints redundantes, permisos inconsistentes, respuestas demasiado amplias, rutas difíciles de gobernar y mayor exposición accidental. En cambio, una arquitectura clara facilita la protección, la observabilidad y la evolución segura del sistema.
Por eso, antes de estudiar amenazas específicas, conviene entender cómo está compuesta una API REST y qué elementos definen su superficie de ataque.
Una API REST suele involucrar varios componentes que trabajan en conjunto. Desde el punto de vista de seguridad, cada uno puede introducir controles o riesgos.
| Componente | Función | Riesgos de seguridad asociados |
|---|---|---|
| Cliente | Consume la API y envía solicitudes | Manipulación de parámetros, robo de tokens, automatización abusiva |
| Endpoint | Expone un recurso o acción | Exposición excesiva, métodos no controlados, enumeración |
| Capa de negocio | Aplica reglas del sistema | Errores de lógica, validaciones débiles, autorizaciones incorrectas |
| Base de datos | Persiste y consulta información | Inyecciones, acceso lateral, fuga de datos |
| Gateway o proxy | Intermedia tráfico y aplica políticas | Configuraciones inseguras, confianza excesiva, reglas inconsistentes |
| Servicios externos | Integran pagos, identidad, mensajería u otros | Dependencia de terceros, secretos expuestos, trust boundary difusa |
REST organiza la API alrededor de recursos: entidades del dominio que pueden identificarse, consultarse y, en algunos casos, modificarse. Ejemplos comunes son usuarios, pedidos, productos, facturas o sesiones.
Diseñar bien los recursos ayuda a evitar APIs caóticas y reduce la necesidad de endpoints especiales difíciles de asegurar. Cuando el modelo de recursos es claro, también es más sencillo razonar sobre permisos, ownership, relaciones y límites de exposición.
Desde el punto de vista de seguridad, cada recurso plantea preguntas clave:
Un endpoint es la combinación práctica de una ruta, un método HTTP y el comportamiento asociado. Por ejemplo, `GET /usuarios/123` y `DELETE /usuarios/123` comparten una ruta base, pero representan riesgos distintos.
La seguridad no se decide solo por endpoint, sino por operación. Dos operaciones sobre el mismo recurso pueden requerir permisos, validaciones y niveles de monitoreo completamente diferentes.
Las rutas deberían reflejar recursos y relaciones del dominio, no detalles internos improvisados. Rutas consistentes ayudan a gobernar permisos, documentación y monitoreo. Rutas confusas o excesivamente custom suelen terminar exponiendo operaciones que no siguen un patrón de control uniforme.
| Diseño | Ejemplo | Riesgo o ventaja |
|---|---|---|
| Claro y orientado a recursos | `GET /pedidos/584` | Facilita permisos por recurso y trazabilidad |
| Relacional y explícito | `GET /usuarios/25/pedidos` | Ayuda a entender ownership y contexto |
| Acción interna poco clara | `POST /doOrderStuff` | Dificulta auditoría, autorización y mantenimiento |
| Ruta administrativa expuesta | `POST /admin/rebuild-cache` | Alta criticidad si no está aislada y protegida |
| Ruta experimental olvidada | `GET /beta/users-all` | Posible fuga de datos o bypass de controles |
Los identificadores forman parte del diseño de la API y pueden convertirse en un vector de ataque si no se acompañan de autorización adecuada. El problema no es que el ID sea predecible o no; el problema real es si la API autoriza correctamente el acceso al objeto referenciado.
Sin embargo, ciertos esquemas de identificación hacen más fácil la enumeración:
La defensa correcta no es esconder identificadores, sino aplicar verificación de acceso objeto por objeto.
Muchas APIs no exponen recursos aislados, sino relaciones: pedidos de un usuario, archivos de un proyecto, comentarios de una publicación, miembros de una organización. Esas relaciones agregan complejidad a la autorización.
Cuando una API navega relaciones jerárquicas, debe validar no solo el objeto final, sino también el contexto del camino. Por ejemplo, que un usuario pueda ver un proyecto no implica automáticamente que pueda ver todos sus documentos, ni modificar todos sus adjuntos.
Los endpoints de listado y búsqueda suelen ser más delicados de lo que parecen. Aunque no modifiquen datos, pueden facilitar enumeración masiva, scraping, descubrimiento de estructura interna y exposición excesiva de atributos.
Ejemplos típicos de riesgo:
El versionado ayuda a evolucionar la API sin romper clientes, pero también puede multiplicar la superficie de ataque. Cada versión mantenida es otra interfaz que requiere autenticación, autorización, monitoreo, pruebas y parches.
Los riesgos más comunes del versionado son:
La superficie de ataque de una API no se reduce a la lista de rutas documentadas. Incluye todos los puntos desde los que un actor puede aprender, probar, automatizar, abusar o degradar el sistema.
En términos prácticos, la superficie de ataque incluye:
Hay decisiones de arquitectura que tienden a aumentar el riesgo porque expanden el número de caminos posibles o hacen más difícil aplicar controles consistentes.
Así como ciertas decisiones agrandan la exposición, otras ayudan a reducirla y hacerla más gobernable.
La estructura de despliegue también influye en la seguridad. Una API monolítica concentra lógica y exposición en un mismo bloque, mientras que una arquitectura de microservicios distribuye funciones entre varios servicios que se comunican entre sí.
| Modelo | Ventaja | Riesgo típico |
|---|---|---|
| Monolito | Menor dispersión de controles | Gran impacto si el punto de entrada falla |
| Microservicios | Separación funcional y escalabilidad | Más trust boundaries, tokens, rutas y tráfico interno |
| Gateway centralizado | Políticas comunes en un punto | Falsa sensación de seguridad si los servicios internos no validan |
Ningún modelo es seguro por sí mismo. Lo importante es que la arquitectura permita aplicar controles consistentes y verificables.
La documentación de una API es necesaria para desarrolladores y consumidores, pero también puede facilitar el reconocimiento para un atacante. Un archivo OpenAPI o Swagger bien expuesto revela rutas, parámetros, modelos, ejemplos y esquemas de autenticación.
Eso no significa que documentar sea un error. Significa que la documentación también forma parte de la superficie de ataque y debe gobernarse:
Entender la arquitectura de una API REST es fundamental para asegurarla correctamente. Los recursos que se exponen, la forma en que se identifican, las relaciones entre ellos y los componentes que participan en cada solicitud determinan la superficie de ataque inicial sobre la que luego actuarán la autenticación, la autorización y el resto de los controles.
En el próximo tema estudiaremos HTTP, métodos, cabeceras y códigos de estado para comprender cómo el protocolo subyacente influye en el comportamiento y en los riesgos de una API REST.