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.
Por qué deberían existir tanto cuotas por cuenta como cuotas por red
Una cuota a nivel de cuenta responde a una pregunta sencilla: cuánto ha usado esta clave concreta. Es lo primero que resulta natural controlar, y no basta por sí sola, porque una clave no es más que una credencial, y las credenciales se pueden multiplicar. Alguien decidido a superar un límite a nivel de cuenta a menudo puede simplemente crear otra cuenta, generar otra clave y empezar con una cuota nueva, a menos que otra cosa esté controlando una dimensión que no se reinicia solo porque se haya emitido una nueva credencial.
Para eso sirven las cuotas a nivel de red. Cada red, un bloque /24 para direcciones IPv4 o un bloque /48 para IPv6, recibe una cuota gratuita compartida de 2.500 solicitudes al día, contada entre el tráfico sin clave y cualquier clave registrada desde esa red. Un límite solo a nivel de cuenta permitiría a alguien generar claves nuevas indefinidamente para seguir reiniciando su cuota gratuita. Un límite a nivel de red cierra ese hueco concreto, porque controla de dónde procede realmente el tráfico, no solo qué credencial iba asociada a él.
Ninguna de las dos medidas basta por sí sola, y vale la pena precisar contra qué protege cada una, ya que resuelven problemas distintos. El control a nivel de cuenta protege contra el uso de una sola credencial muy por encima de lo que debería, lo que importa para la exactitud de la facturación y para detectar una clave filtrada que se está usando donde no debería. El control a nivel de red protege específicamente contra la multiplicación de la cuota gratuita mediante registros repetidos, que es un modo de fallo distinto que el control a nivel de cuenta por sí solo no puede ver, ya que cada cuenta nueva parece perfectamente normal de forma aislada.
Aplicar ambas a la vez sí genera una complicación legítima: varios usuarios reales que comparten una red, como una empresa detrás de un pequeño número de direcciones IP públicas, podrían en teoría toparse con un techo a nivel de red que no tiene nada que ver con el uso real de ningún usuario individual. Lo resolvemos con espacios de IP rotativos, un número fijo de direcciones distintas desde las que se puede usar una clave, y con cabeceras de cuota que muestran exactamente cuántos de esos espacios están en uso frente al límite, para que una red compartida legítima pueda ver su situación real en lugar de chocar con un muro opaco sin ninguna explicación.
Creemos que este es un caso en el que el diseño más simple, controlar una sola dimensión, sería en realidad peor para los usuarios honestos, no solo menos protector frente al abuso. Un límite solo de red penalizaría a una cuenta por otra actividad no relacionada en la misma red. Un límite solo de cuenta dejaría la cuota gratuita expuesta a multiplicarse indefinidamente por cualquiera dispuesto a crear suficientes cuentas. Aplicar ambos, con visibilidad de cada uno a través de las cabeceras de respuesta, implica más piezas en movimiento, pero es la versión que realmente protege lo que una cuota gratuita debe proteger sin castigar discretamente a quienes la usan como se pretende.