El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Lo que resuelve la limitación de frecuencia por red que los límites por clave no resuelven
Un límite de frecuencia vinculado solo a una clave de API hace una suposición silenciosa: que una clave corresponde a un usuario legítimo que la usa de una forma razonablemente predecible. Esa suposición falla con más frecuencia de lo que el diseño prevé. Una clave puede compartirse en un equipo, integrarse en una aplicación del lado del cliente en la que muchos visitantes distintos lanzan solicitudes con la misma credencial, o generarse muchas veces por alguien que intenta precisamente acumular varias claves para sortear el límite de una sola.
Aplicamos el límite de frecuencia a nivel de red además de a nivel de clave precisamente por esta razón. Cada red, un bloque /24 para IPv4 o un bloque /48 para IPv6, recibe una cuota gratuita de 2.500 solicitudes al día que se comparte entre el uso sin clave y cualquier clave registrada desde direcciones de esa red. Una persona no puede generar diez claves desde la misma red y multiplicar por diez su cuota gratuita, porque el techo a nivel de red detecta ese patrón sin importar cuántas claves distintas haya por debajo.
No se trata principalmente de frenar el abuso malintencionado, aunque también lo hace. Se trata de que la cuota gratuita siga siendo significativa para todos los que la usan honestamente. Un recurso compartido como un plan gratuito solo sigue siendo generoso si esa generosidad no la acapara discretamente en masa un pequeño número de cuentas que sortean el límite por clave. Las cuotas a nivel de red mantienen las cuentas del plan gratuito más cerca de lo que realmente se diseñó para ofrecer: una cuota diaria real por origen, no por cada credencial que ese origen tenga.
Hay un caso de uso legítimo al que esto debe tener cuidado de no penalizar: varios usuarios o servicios genuinos que operan legítimamente desde la misma red, como una oficina, un entorno de alojamiento compartido o una gran organización detrás de un pequeño número de direcciones IP públicas. Precisamente por eso publicamos los espacios de IP rotativos y damos visibilidad del uso de la red mediante cabeceras de cuota, incluida una cabecera específica que indica cuántos de los espacios de IP de tu clave están en uso respecto al límite. Un equipo legítimo que comparte una red puede ver su situación real en lugar de descubrir un techo compartido solo cuando lo alcanza de forma inesperada.
Limitar la frecuencia solo a nivel de clave es más sencillo de construir y de explicar, y para muchas API probablemente es suficiente. Para un servicio con un plan gratuito significativo en concreto, limitar solo por clave deja un hueco evidente: la cuota gratuita nunca se pensó como un recurso que se pudiera multiplicar generando más credenciales, y un límite que no lo tiene en cuenta no protege realmente lo que dice proteger. Añadir un techo a nivel de red por encima del de nivel de clave cierra ese hueco sin exigir a cada usuario legítimo que demuestre que no es la excepción.