Límites de uso y tamaños

El consumo irrestricto de recursos (API4:2023 en la lista OWASP API Security Top 10 de 2023) agrupa lo que puede agotar una API: demasiadas peticiones, cuerpos enormes, páginas con miles de filas, listas sin tope de elementos, tiempos de respuesta sin cota. El efecto va de la factura de nube que se dispara a la caída del servicio.

En el contrato se declaran con maximum, maxLength y maxItems; en el gateway, con límites por ruta. Cada capa cubre lo que la otra no ve.

Un parámetro de paginación sin maximum permite pedir una página de cualquier tamaño: un solo cliente puede obligar al servidor a leer y serializar millones de filas. Los dos parámetros bien escritos de listarPedidos sirven de referencia: ambos declaran su máximo.

Lee los fragmentos de parámetros y busca el que no declara máximo.

Hay rutas donde un límite flojo es peor que en otras: las que inician flujos sensibles de negocio, como el acceso o la recuperación de credenciales, son el blanco natural de la automatización (API6:2023 en la lista OWASP). Sin límite de peticiones, alguien puede probar combinaciones sin freno.

Lee la tabla de límites del gateway y busca la ruta que no tiene ninguno.

Un cuerpo de petición grande se paga en memoria, red y tiempo de proceso, y en una ruta sin motivo para recibir archivos es una invitación al abuso. El tamaño máximo del cuerpo se fija por ruta: lo normal es un megabyte; lo mayor debe justificarse con una necesidad del negocio.

El límite por minuto solo sirve si se cuenta por la clave correcta. La política del gateway lo cuenta por dirección de origen: varios clientes legítimos detrás de una misma salida a internet comparten el cupo y se bloquean entre sí, y quien tiene muchas direcciones lo esquiva. Un límite mejor se cuenta por credencial autenticada y por ruta, más estricto en los flujos sensibles.

El registro de la última semana muestra dónde se disparan los 429: el límite global parece funcionar, pero no protege lo que más importa.