La pasarela de APIs como punto de control

La pasarela se sienta entre los consumidores y los servicios y aplica controles que no dependen del negocio de cada API: autentica al consumidor (una sesión, una llave, un certificado), limita la frecuencia y el volumen por consumidor o por dirección, valida que la petición tenga la forma que declara el contrato y deja un registro uniforme de todo. Centralizarlo evita que cada equipo lo implemente a su manera, o que se le olvide.

Lo que la pasarela no sabe es de quién es cada objeto. Puede comprobar que la petición trae una sesión válida del socio S-30418, pero no que la receta R-55160 sea de ese socio: eso lo sabe el servicio, que tiene los datos. La autorización a nivel de objeto, el riesgo número uno del Top 10 de OWASP para APIs de 2023 (API1:2023), sigue siendo trabajo del código.

Abre el laboratorio y lee pasarela.yaml. Cada ruta declara sus controles. Una ruta sin autenticación puede ser una decisión aprobada o un olvido; la diferencia está escrita, o no, al lado.

La topología dice que los servicios solo reciben tráfico de la pasarela. Esa frase es un diseño, no un hecho: se comprueba en la configuración de lo que está delante. Lee balanceador.txt y compara el destino de cada regla con las direcciones de topologia.txt.

registro-recetas.txt es el registro del servicio, no de la pasarela, y anota la dirección desde la que le llegó cada conexión. La topología te dice qué dirección interna tiene la pasarela y cuál el balanceador. Fíjate también en la columna X-Consumidor: el servicio la confía porque supone que la escribió la pasarela.

Por la puerta lateral no hay autenticación, ni límite, ni validación de esquema, y además el servicio cree a quien escriba la cabecera del consumidor: tres de esas peticiones dicen ser de consumidores registrados, y nada lo comprueba. La corrección tiene que impedir que vuelva a pasar aunque alguien cree otra regla de prueba.