Tema 19
Las APIs rara vez quedan expuestas directamente al backend puro. En la práctica suelen existir capas intermedias que reciben, enrutan, inspeccionan, autentican, limitan y observan el tráfico antes de llegar al servicio real. Bien diseñadas, estas capas mejoran seguridad y operación. Mal entendidas, generan una peligrosa ilusión de protección que deja huecos críticos detrás del perímetro.
En arquitecturas reales, la API no suele ser el primer componente que recibe una solicitud desde internet. Antes pueden aparecer un CDN, un balanceador, un proxy inverso, un API Gateway, un WAF o una combinación de varios. Cada uno puede aportar controles valiosos, pero también introduce complejidad y puntos de confianza adicionales.
Estas capas son útiles para centralizar políticas, limitar abuso, observar tráfico, terminar TLS, aplicar autenticación preliminar o aislar servicios internos. Sin embargo, no reemplazan la seguridad del backend. Si el servicio final asume que “el gateway ya protegió todo”, aparecen fallas graves de autorización, validación y lógica.
Este tema analiza qué hace cada capa, dónde agrega valor y cuáles son los errores conceptuales más frecuentes al usarlas.
Las capas de protección son componentes intermedios que actúan antes o alrededor de la API para filtrar, transformar, enrutar, limitar o inspeccionar tráfico. Forman parte de una estrategia de defensa en profundidad.
Entre las más comunes están:
Un proxy inverso recibe solicitudes en nombre del backend y las reenvía a uno o varios servicios internos. Puede ocultar topología interna, terminar TLS, manejar compresión, aplicar cabeceras, registrar tráfico y hacer routing básico.
Desde seguridad, aporta valor porque:
Los balanceadores suelen enfocarse en disponibilidad y escalado, pero también tienen implicancias de seguridad. Pueden controlar terminación TLS, health checks, routing por host o path, y a veces primeras capas de filtrado.
Errores comunes en este nivel incluyen:
Un API Gateway es una capa especializada para exponer y gobernar APIs. Suele ofrecer autenticación preliminar, validación básica, routing, rate limiting, versionado, transformación de requests/responses, métricas, observabilidad y aplicación centralizada de políticas.
Su valor principal está en unificar controles comunes para múltiples servicios y ofrecer una superficie de exposición más ordenada y gobernable.
| Control | Qué aporta |
|---|---|
| Autenticación preliminar | Bloquea solicitudes obviamente no autenticadas o inválidas |
| Rate limiting | Limita consumo y abuso antes de llegar al backend |
| Routing | Expone de forma ordenada múltiples servicios |
| Transformación | Normaliza headers, rutas o formatos |
| Observabilidad | Concentra métricas, logs y tracing de entrada |
| Políticas comunes | Evita repetir controles básicos en cada servicio |
Aunque el gateway ayude mucho, no debería tomarse como autoridad suficiente para decisiones de negocio fino. El servicio real sigue necesitando validar:
El gateway suele ver bien el perímetro, pero no el detalle completo del dominio.
Un Web Application Firewall inspecciona solicitudes HTTP para detectar y bloquear patrones asociados a ataques conocidos o anómalos. Puede ayudar frente a ciertas inyecciones, payloads maliciosos, escaneo básico o firmas conocidas de abuso.
Su fortaleza está en agregar una defensa extra, especialmente ante ataques genéricos o automatizados. Su límite es que no entiende profundamente la lógica del negocio ni reemplaza validación y autorización correcta en la API.
El error más frecuente con WAFs es asumir que “si pasa por el WAF, está seguro”. Esa idea es técnicamente débil por varias razones:
Muchas de estas capas terminan TLS y, por tanto, ven tráfico ya descifrado. Eso les permite inspeccionar, limitar y enrutar, pero también implica que pasan a formar parte del perímetro de confianza y del problema de protección de datos sensibles.
Esto obliga a preguntarse:
Cuando el tráfico pasa por proxies o gateways, suelen agregarse cabeceras con información sobre IP de origen, host original, protocolo o trazabilidad. El backend puede usarlas para auditoría, rate limiting o decisiones contextuales.
El riesgo aparece cuando el backend confía en esas cabeceras sin verificar que provienen de infraestructura confiable. Si un cliente puede inyectarlas o alterarlas, puede falsear origen, bypass de controles o distorsionar investigación.
Una ventaja de gateways y proxies es centralizar políticas comunes. Pero no todo debe centralizarse. Hay que distinguir entre:
Centralizar demasiado puede volver opaca y frágil la lógica. Distribuir todo puede volverla inconsistente. El diseño correcto encuentra el punto de equilibrio.
En arquitecturas de microservicios, el gateway suele ser la puerta de entrada externa y simplifica la exposición del sistema. Pero detrás de esa puerta siguen existiendo múltiples servicios con confianza parcial entre sí.
Errores comunes en este escenario:
Uno de los grandes beneficios de estas capas es la observabilidad. Pueden registrar métricas de tráfico, errores, latencia, abuso y rutas activas antes de que las solicitudes lleguen al backend. Eso mejora detección temprana y análisis de incidentes.
Sin embargo, también hay que gobernar esa observabilidad para no convertirla en una fuga de tokens, payloads sensibles o metadata excesiva.
Los proxies y gateways también pueden ayudar a segmentar superficies distintas: pública, privada, administrativa o interna. Esa separación reduce confusión de políticas y minimiza el riesgo de exponer rutas o funciones críticas por accidente.
Ejemplos útiles:
Las capas intermedias son una herramienta poderosa para reforzar la seguridad de APIs REST, siempre que se entiendan como una parte de una defensa en profundidad y no como una solución total. API Gateways, WAFs y proxies inversos permiten centralizar controles, aislar superficies y mejorar observabilidad, pero la seguridad real sigue dependiendo de que el backend valide, autorice y procese con rigor. El perímetro puede ayudar mucho; no debería ser la única línea de pensamiento.
En el próximo tema estudiaremos observabilidad, logging, trazabilidad y detección de anomalías, para ver cómo transformar el tráfico y los eventos de la API en capacidad real de detección e investigación.