Tema 1
La seguridad en APIs REST estudia cómo proteger los puntos de acceso que conectan aplicaciones, clientes, sistemas internos y servicios de terceros. Su propósito no es solo impedir ataques técnicos, sino garantizar que los datos y las operaciones expuestas por una API sean consumidos de forma controlada, legítima y resiliente.
Las APIs REST se han convertido en una pieza central del software moderno. Aplicaciones web, apps móviles, paneles administrativos, microservicios, integraciones B2B, automatizaciones y servicios en la nube dependen de APIs para intercambiar datos y ejecutar acciones.
Esa capacidad de conexión hace a las APIs extremadamente valiosas, pero también las vuelve un objetivo directo. Si una API está mal diseñada o mal protegida, un atacante puede leer información sensible, modificar recursos, abusar de funcionalidades, automatizar fraudes o provocar indisponibilidad.
Por eso, asegurar una API no consiste solo en exigir un token. Implica definir qué recursos se exponen, quién puede acceder, bajo qué condiciones, cómo se validan los datos, qué operaciones son permitidas, cómo se limita el abuso y cómo se detecta actividad anómala.
Una API REST es una interfaz que expone recursos y operaciones a través del protocolo HTTP. Los clientes interactúan con endpoints utilizando métodos como GET, POST, PUT, PATCH o DELETE para consultar, crear, modificar o eliminar información.
En una API REST, la comunicación suele ser stateless, basada en mensajes HTTP, cabeceras, parámetros y cuerpos normalmente serializados en JSON. Aunque este estilo simplifica el consumo e integración, también expone una superficie clara de ataque: URLs, métodos, datos de entrada, tokens, respuestas, errores y reglas de negocio.
Las APIs suelen exponer información de alto valor y capacidades sensibles: cuentas de usuarios, transacciones, historiales, catálogos, pagos, validaciones, procesos administrativos, sincronización entre sistemas y acceso a funcionalidades internas.
Además, muchas veces la API es el verdadero backend del negocio digital. La interfaz visible puede ser una app o un sitio web, pero las operaciones reales ocurren en la API. Si esa capa es vulnerable, el atacante puede omitir la interfaz y hablar directamente con el backend.
| Elemento | Qué aporta | Qué pasa si se compromete |
|---|---|---|
| Endpoints de datos | Exponen recursos y consultas del sistema | Filtración masiva o acceso indebido a información sensible |
| Operaciones críticas | Permiten crear, actualizar o borrar recursos | Fraude, manipulación de estados y daño operativo |
| Tokens y credenciales | Controlan autenticación y sesiones | Suplantación de identidad y acceso persistente |
| Integraciones externas | Conectan terceros, socios o servicios internos | Abuso de confianza y propagación de incidentes |
| Consumo automatizado | Facilita escalabilidad y operación continua | Abuso a gran escala, scraping, fuerza bruta o DoS |
La seguridad en APIs REST protege tanto la capa técnica de exposición como la lógica de negocio que esa exposición habilita. No alcanza con proteger el servidor o la red; hay que proteger los recursos, operaciones y reglas que la API representa.
Esto incluye proteger:
Los objetivos de protección indican qué debe preservarse al diseñar o defender una API. Son el marco que guía decisiones sobre autenticación, validación, autorización, cifrado, monitoreo y hardening.
En APIs modernas, estos objetivos están profundamente conectados. Una falla de autorización puede afectar confidencialidad e integridad al mismo tiempo; una mala validación puede impactar disponibilidad y exposición de datos.
Una API funcional responde correctamente a las solicitudes esperadas. Una API segura responde correctamente bajo control, incluso frente a entradas maliciosas, usuarios curiosos, automatización abusiva y condiciones no ideales.
Muchas APIs cumplen su función de negocio pero siguen siendo inseguras por problemas como estos:
Las APIs están expuestas a una mezcla de amenazas técnicas y fallas de lógica. En muchos casos, el ataque no busca romper el servidor, sino usar la API exactamente como fue diseñada, pero con intenciones no previstas por el negocio.
La superficie de ataque es el conjunto de puntos por los que una API puede ser observada, utilizada, forzada o abusada. No se limita a una URL pública; incluye el modelo de autenticación, los objetos expuestos, los parámetros admitidos, la documentación publicada, los mensajes de error y las dependencias internas o externas.
En una API REST, esa superficie suele incluir:
Reducir superficie de ataque no significa hacer una API inútil. Significa exponer solo lo necesario, validar mejor y observar más de cerca lo que debe permanecer disponible.
Antes de entrar en herramientas y estándares, conviene fijar los principios de diseño que suelen repetirse en APIs bien protegidas.
Un punto clave en APIs es distinguir entre vulnerabilidades técnicas tradicionales y fallas de lógica. Una API puede tener HTTPS, JWT y validaciones básicas, y aun así ser vulnerable porque permite una acción que no debería permitir desde el punto de vista del negocio.
| Tipo de problema | Ejemplo | Impacto |
|---|---|---|
| Técnico | Inyección SQL en un endpoint de búsqueda | Compromiso de datos o ejecución no prevista |
| Autenticación | Tokens sin expiración o mal protegidos | Suplantación de identidad |
| Autorización | Acceso a pedidos de otro usuario cambiando el ID | Violación de privacidad e integridad |
| Lógica de negocio | Aplicar descuentos o reintentos ilimitados | Fraude o abuso funcional |
| Operativo | Sin rate limiting ni detección de abuso | Sobrecarga, scraping o automatización maliciosa |
Los objetivos de protección se entienden mejor cuando se los vincula con situaciones reales.
La defensa de una API es el resultado de combinar varias capas. Ningún mecanismo aislado resuelve el problema completo.
La seguridad de una API no debería añadirse al final. Debe aparecer desde el diseño del recurso, la definición del contrato, la elección del esquema de autenticación, el modelado de permisos y las pruebas previas al despliegue.
Esto implica que desarrollo, seguridad, operaciones y producto deben coordinarse. Si el diseño del negocio es inseguro, corregirlo después del lanzamiento suele ser más costoso, más lento y más riesgoso.
Este primer tema define el marco general. En los próximos temas veremos cómo traducir estos principios a controles concretos de diseño, implementación y operación.
La seguridad en APIs REST es esencial porque las APIs son el canal por el que circulan datos sensibles y operaciones clave del sistema. Protegerlas requiere pensar en amenazas técnicas, abuso funcional, control de acceso, resiliencia y trazabilidad como parte de una misma disciplina.
En el próximo tema estudiaremos la arquitectura de APIs REST, los recursos, los endpoints y cómo esa estructura define la superficie de ataque inicial de una API.