Elusión de autorización en API Gateway: 7 errores comunes de configuración y cómo protegerse

Cada vez hay más servicios, y las puertas de enlace por las que se comunican con el mundo exterior se han convertido en un elemento vital de la arquitectura. Desafortunadamente, es precisamente ahí donde con frecuencia se esconden fallos pequeños a primera vista que convierten una barrera de protección en puertas abiertas. En este artículo analizaremos cómo una falta de atención habitual al configurar un API Gateway permite eludir la autorización y qué hacer al respecto.

Por qué eludir la autorización a través del API Gateway sigue siendo un problema

Parece que la infraestructura en la nube moderna es suficientemente segura "de fábrica". Pero las estadísticas de incidentes demuestran lo contrario: cada año se hacen públicas decenas de filtraciones cuya raíz fueron un par de casillas mal marcadas en la consola. Al atacante ni siquiera le hace falta buscar un 0-day complejo: basta con esperar una nueva versión de la aplicación, cuando un ingeniero tenía prisa por el lanzamiento y temporalmente desactivó la casilla «Autorización — obligatoria», y luego se olvidó de volver a activarla.

Qué es un API Gateway y qué mecanismos de autorización ofrece

Un API Gateway es una capa proxy entre clientes y un conjunto de microservicios. Enruta las solicitudes, las transforma y, sobre todo, verifica si el usuario puede ejecutar un método determinado. Según la plataforma, hay distintos métodos de autorización disponibles:

OAuth 2.0 / OpenID Connect — autenticación por token, compatible con la mayoría de clientes modernos.
Políticas IAM (AWS, GCP, Yandex Cloud) — reglas a nivel de cuenta que determinan quién y qué puede invocar.
Claves de acceso (API keys) — tokens simples que se envían en el encabezado o en la cadena de consulta.
Autorizadores Lambda / custom authorizers — función personalizada que valida la solicitud conforme a reglas propias.

En la práctica, los desarrolladores combinan métodos: por ejemplo, los endpoints públicos se protegen con API key y los internos con JWT. Cuanto más compleja es la arquitectura, mayor es la probabilidad de que haya inconsistencias en la configuración.

Errores típicos de configuración que permiten eludir la autorización

A continuación se exponen siete escenarios que aparecen con frecuencia en auditorías y programas de bug bounty. Los nombres de los campos pueden variar entre nubes, pero la esencia es la misma.

Método «ANY» sin autorización. En la interfaz es cómodo seleccionar «ANY» para que una regla admita GET, POST, DELETE y otros métodos a la vez. Si para un método concreto la autorización está activada, pero para «ANY» no, el atacante puede invocar PATCH /resource y eludir las comprobaciones.
Diferentes etapas (stages), distintas reglas. Supongamos que existen dev, staging y prod. Con frecuencia se olvida que las políticas no se copian automáticamente: una etapa sin protección puede llegar a producción y solo detectarse después del incidente.
Caché de autorización. Para reducir la latencia, el gateway cachea el resultado de la verificación del token, por ejemplo, durante cinco minutos. Si en el caché queda la decisión de "permitir" y el rol del usuario ya fue revocado, el token antiguo puede seguir funcionando.
Reglas wildcard excesivas. Una política como "arn:aws:execute-api:*:*:*/GET/*" es más simple que enumerar cada ruta, pero permite acceso a todos los recursos, incluso a los que deberían ser privados.
Roles de integración no contemplados. La autorización puede aprobar la solicitud, pero luego el backend recibe la petición con la identidad de una rol que tiene más permisos de los necesarios. Como resultado, un usuario "restringido" se convierte en administrador a nivel de base de datos.
La función de autorización devuelve un estado incorrecto. El authorizer personalizado debe responder con 403 si algo falla. Algunos desarrolladores, por error, devuelven 200 con un texto de error; para el gateway eso es señal de "todo bien" y la solicitud pasa.
Endpoint paralelo sin autorización. Al migrar versiones del API se deja la ruta antigua (por ejemplo /v1/…) "por compatibilidad" y se le asigna una ruta simplificada. Si el nuevo /v2/… exige autorización y el heredado /v1/… no se cierra, el atacante usa la ruta antigua y obtiene la misma funcionalidad sin token.

Ejemplo práctico: cómo un atacante explota una brecha de configuración

Imaginemos un servicio SaaS que almacena informes de usuarios. En /reports/{id} se añadió el método DELETE, pero se olvidó activar la autorización en «ANY» — el probador estaba depurando el servicio con Postman.

El atacante hace OPTIONS /reports/123 para comprobar qué métodos están disponibles.
Observa que DELETE no requiere autorización.
Envía DELETE y el gateway ejecuta la petición porque la regla «ANY» funciona sin token.
El informe del usuario se elimina y el registro de actividad queda vacío — la autorización "no falló".

En la nube, esto puede combinarse con credenciales temporales indefinidas, un bucket S3 vulnerable o JWT filtrados en logs. El resultado es el mismo: una negligencia en la configuración se convierte en un exploit sin código complejo.

Cómo detectar el problema en una etapa temprana

La mayoría de fallos tipo "casilla mal puesta" se detectan bien con automatización, si esta está configurada.

Herramientas como OWASP ZAP y Scout Suite. Hacen un barrido de la cuenta en la nube y señalan políticas con wildcard.
Comprobaciones CI/CD del código de infraestructura. Si las configuraciones (Terraform, CloudFormation, Pulumi) se almacenan en Git, ejecute Checkov o KICS en cada pull request.
Alertas de Security Hub / CloudTrail. Cualquier anomalía (por ejemplo, borrados masivos con DELETE sin token) debe generar un incidente en Slack o en la SIEM.
Rotación de etapas de prueba. Si en dev se desactivó la autorización por conveniencia, un script automático debe restaurar la configuración por defecto antes de fusionar en prod.

Estrategia de auditoría paso a paso para DevOps y equipos de seguridad

Reúna la inventario. Extraiga la lista de todos los API Gateway, etapas, nombres de dominio asociados a la cuenta.
Agrúpelos por contexto de acceso. Públicos, privados, de socios.
Verifique cada recurso-método. ¿Tiene authorizer? ¿Cuál: clave, IAM o JWT?
Compare la configuración declarativa y la real. ¿Terraform indica que la protección está activada pero en la consola aparece desactivada? Busque la causa de inmediato.
Realice pruebas negativas. Envíe la solicitud sin token y espere 401. ¿Recibió 200? Entonces hay una brecha.
Revise los roles de integración. Asegúrese de que la identidad con la que llama el gateway no tenga permisos excesivos.
Implemente pruebas de regresión. Cada nuevo endpoint debe fallar inicialmente sin autorización — ese debe ser un caso de prueba obligatorio.

Mejores prácticas de protección

Principio del denegado por defecto. Permita acceso solo a lo descrito en la política; no use wildcard.
Infraestructura como código. Guarde la configuración del gateway como código para evitar cambios "en caliente" vía UI.
Active el registro a nivel de gateway. Es barato y facilita mucho las investigaciones.
Granule los roles. Haga que el API Gateway invoque el backend con una rol de servicio separada y con mínimos permisos.
Revisiones regulares por terceros. Contrate auditores para que busquen errores de configuración, no solo inyecciones.
Mantenga el motor del gateway actualizado. Muchas vulnerabilidades se corrigen con parches.

Herramientas que ayudan cada día

A continuación, servicios útiles que alivian parte de la rutina:

OWASP ZAP — comprobación rápida para vulnerabilidades básicas.
Burp Suite — herramienta versátil para pruebas manuales de API.
Scout Suite — auditoría de configuraciones en la nube.
IAM Access Analyzer — detecta recursos en AWS con permisos excesivos.
Semgrep — análisis estático de código y archivos IaC.
Grafana Loki + Prometheus — stack económico para logs y alertas.

Preguntas frecuentes

¿Se puede desactivar la autorización durante la depuración?

Se puede, pero solo localmente o en una cuenta de pruebas aislada que no sea accesible desde Internet. Cualquier concesión "temporal" en un entorno de producción seguramente se olvidará.

¿Es suficiente poner un WAF delante del gateway?

Un firewall web detecta inyecciones SQL y XSS, pero no protege contra una "autorización desactivada". Por eso el WAF es útil pero complementario.

¿Qué hacer si el fallo ya llegó a producción?

Primero cierre la brecha: active la autorización, limite direcciones IP sospechosas y revoque las claves emitidas. Después analice los logs para entender el alcance de la intrusión. Y, finalmente, ponga en marcha procesos que eviten la repetición: code review, escáneres automáticos y control mediante pull request.

Conclusión

Para que un atacante no pueda eludir la autorización, aplique el principio del mínimo privilegio, guarde las configuraciones de infraestructura en un sistema de control de versiones, automatice las comprobaciones y considere la seguridad como parte integral del ciclo de vida del desarrollo.

Realice pruebas de penetración solo en sistemas para los que tenga autorización oficial. El acceso no autorizado es ilegal.