Limitación de tasa de API: control práctico y prevención del abuso

Qué problema estás resolviendo (en términos simples)

Una API pública es como una recepción que nunca cierra. La mayoría de la gente pide una cosa y se va. El abuso ocurre cuando alguien (o algún código defectuoso) golpea esa recepción tan seguido que todos los demás quedan esperando.

El abuso rara vez es una sola cosa. Puede ser scraping (extraer grandes cantidades de datos rápidamente), intentos de fuerza bruta (adivinar contraseñas o claves de API), o un cliente fuera de control que reintenta en bucle tras un error. A veces ni siquiera es malicioso: un despliegue defectuoso puede convertir una app normal en el "atacante" más ruidoso que tengas.

Es tentador "bloquearlos" de forma tajante, pero las reglas contundentes castigan a usuarios reales. Muchos clientes comparten IPs (oficinas, colegios, cafeterías). Las redes móviles rotan IPs. Algunos SDKs reintentan automáticamente. Si tu regla es demasiado amplia, bloqueas a las personas equivocadas y aun así fallas en atrapar al verdadero abusador.

Las señales tempranas suelen aparecer en logs y dashboards: picos de tráfico que no casan con el uso normal, mayor tasa de errores (timeouts, 429, 5xx), respuestas más lentas, una mezcla extraña de endpoints (un endpoint de lista llamado miles de veces por minuto), o muchos intentos de auth fallidos y peticiones "casi válidas".

El objetivo de la limitación de tasa es simple: mantener la API disponible y predecible para usuarios normales, incluso cuando el tráfico se vuelve caótico. Buenos límites ralentizan patrones malos, dan retroalimentación clara a clientes legítimos y te compran tiempo para responder sin tirar abajo todo el servicio.

Mapea tus superficies de API y puntos de riesgo

Antes de elegir números, aclara qué estás protegiendo. La limitación de tasa funciona mejor cuando coincide con la forma real de tu API, no con una regla única para todo.

Empieza listando cada punto de entrada público que un tercero pueda golpear, incluidos los que olvidas porque "parecen internos" (endpoints móviles, llamadas JSON de la app web, rutas para partners). Luego marca qué endpoints son propensos al abuso y cuáles son simplemente costosos.

Las áreas de alto riesgo suelen ser previsibles: login, signup, refresh de token, restablecimiento de contraseña y códigos de verificación, endpoints de búsqueda/filtrado costosos, subidas de archivos o procesamiento de medios, y cualquier acción tipo admin que acabe expuesta por error.

A continuación, decide a quién se aplica un límite:

• El tráfico anónimo suele necesitar límites por IP, pero las IPs son compartidas y pueden rotar.
• El tráfico autenticado puede usar user ID, API key, cliente OAuth u org/workspace ID.
• Productos B2B suelen beneficiarse de límites a nivel de organización para que un cliente no pueda dejar sin recursos a los demás.

Para mantener esto manejable, encasilla endpoints por "coste" para no tratar todo igual. Por ejemplo: lecturas baratas, listas normales con paginación, búsquedas/exports/subidas/llamadas AI costosas, y flujos críticos de auth/contraseña.

Luego define el uso justo en palabras sencillas. ¿Te preocupan las ráfagas cortas (100 peticiones en 10 segundos) o un drenaje sostenido (10.000 al día)? Muchos productos necesitan ambos: una pequeña ráfaga para cargas de página y un tope a más largo plazo para evitar scraping lento.

Si heredaste una API generada por IA, haz este mapeo primero. Equipos como FixMyMess a menudo encuentran endpoints “costosos” ocultos bajo nombres inocentes, además de checks de auth faltantes que convierten a la limitación de tasa en tu última línea de defensa.

Elige un modelo de throttling que coincida con el tráfico real

Una buena limitación de tasa debe sentirse invisible para usuarios normales y muy ruidosa para abusadores. Eso suele significar soportar comportamientos explosivos (cargas de página, reconexiones móviles, reintentos) sin permitir extracción sostenida de alto volumen.

Modelos principales (y cuándo encajan)

Token bucket es la elección común por "buena UX". Cada usuario tiene un cubo que se rellena con el tiempo. Cada petición gasta un token. Si el cubo está lleno, los usuarios pueden hacer una ráfaga rápida y luego desacelerar naturalmente al agotarse los tokens.

Leaky bucket es más estricto. Las peticiones entran en un embudo que se vacía a una velocidad estable. Suaviza bien las ráfagas, lo que puede proteger backends frágiles, pero puede sentirse duro para clientes legítimos que hacen cosas razonablemente explosivas (como abrir varias páginas a la vez).

Fixed window es lo más simple: "100 peticiones por minuto." La trampa es la frontera: un cliente puede hacer 100 peticiones a las 12:00:59 y 100 más a las 12:01:00, lo que son 200 peticiones en dos segundos. Suele estar bien para endpoints de bajo riesgo o como pase inicial cuando la simplicidad importa más que la justicia.

En la práctica, muchos equipos estandarizan en un modelo por defecto y mantienen una opción más estricta para endpoints sensibles:

• Por defecto: token bucket para la mayoría de APIs de lectura/escritura
• Más estricto: leaky bucket (o token bucket con una ráfaga pequeña) para rutas costosas
• Opción simple: fixed window para endpoints de bajo impacto
• Reglas separadas para auth, búsqueda y acciones masivas

Esto mantiene la política simple y aun así protege las rutas que realmente atacan los atacantes.

Decide sobre qué aplicas la limitación (y qué evitar)

La limitación de tasa solo es justa tanto como lo sea el identificador que elijas. Si eliges mal el "quién", bloqueas a buenos usuarios mientras los abusadores se escapan.

La opción más limpia es una API key (o cliente OAuth) porque se mapea a un cliente real y no se comparte por accidente. Un user ID autenticado también es sólido, pero puede complicarse cuando una persona abre muchas sesiones o rota dispositivos. Un org/workspace ID ayuda a imponer límites de plan, pero puede ocultar a un único usuario ruidoso dentro de una cuenta grande.

Los límites basados en IP funcionan antes del login, pero también castigan a usuarios inocentes porque las IPs se comparten por diseño (oficinas, colegios, carriers móviles, VPNs). Si confías solo en la IP, un usuario pesado puede dejar bloqueada a una campus entero.

Una estrategia más segura es combinar señales para que ninguna domine:

• Por usuario o por API key: protege a los clientes entre sí
• Por IP: detecta inundaciones y bots baratos temprano
• Por endpoint: límites más estrictos en rutas costosas (login, búsqueda, exports)
• Por organización: aplica límites de plan sin microgestionar individuos

Para tráfico no autenticado, asume mayor riesgo. Mantén los topes más estrictos, pero da a usuarios legítimos un camino hacia mayor confianza: permite pequeñas ráfagas, luego ralentiza, y fomenta la autenticación antes de acciones de alto volumen.

Ejemplo: para un endpoint público search, limita por API key y por IP. Así un scraper que rota keys seguirá topando con un muro de IP, y un cliente real en una oficina compartida aún tendrá su presupuesto por key.

Si heredaste código generado por IA, verifica que los identificadores sean consistentes entre servicios. FixMyMess suele ver límites ligados a valores inestables (como headers crudos), lo que hace que el throttling parezca aleatorio para los clientes.

Paso a paso: implementa límites sin romper clientes

La limitación de tasa funciona mejor cuando es predecible para usuarios reales y dolorosa solo para abusadores. No buscas bloquear tráfico; buscas moldearlo.

1) Empieza con niveles y reglas simples

Define unos pocos niveles que coincidan con cómo la gente usa tu API: visitantes anónimos, usuarios registrados gratuitos, usuarios pagos y herramientas internas. Mantén la primera versión simple. Puedes añadir matices después.

2) Valora los endpoints por riesgo (y coste)

No todas las peticiones son iguales. Haz que los endpoints costosos o sensibles cuesten más que lecturas básicas. Login, restablecimiento, búsqueda y export son imanes comunes de abuso.

Un enfoque práctico son las peticiones ponderadas: lecturas cuestan 1, login cuesta 5–10, exports 50+, y cualquier cosa que dispare trabajo pesado en BD cuesta más. Esto frena scraping y fuerza bruta sin castigar la navegación normal.

3) Devuelve 429 claros y cabeceras consistentes

Cuando un cliente alcanza el límite, responde con HTTP 429 y un mensaje claro que explique qué pasó y qué hacer. Incluye cabeceras consistentes para que los clientes se autorregulen. Si tu stack lo soporta, envía cuota restante, tiempo de reinicio y un Retry-After.

4) Da orientación segura de reintento

Sé explícito sobre cuándo reintentar es razonable (ráfagas cortas) y cuándo no lo es (cuotas duras, o endpoints como login donde reintentos repetidos parecen ataque). Un mal comportamiento de reintento puede convertir un pequeño pico en un incidente serio.

5) Monitoriza y ajusta con datos reales

Controla con qué frecuencia los usuarios alcanzan límites, qué endpoints disparan 429 y qué identidades son los mayores infractores. Si estás arreglando una app generada por IA (por ejemplo, un prototipo con auth rota y reintentos ruidosos), a menudo encontrarás bucles de cliente accidentales que parecen abuso. Arreglar el comportamiento del cliente puede reducir el dolor de los límites más que subirlos.

Patrones de protección contra bots que no castigan a usuarios normales

La buena protección contra bots se trata menos de levantar un muro y más de añadir pequeños obstáculos donde los bots obtienen más valor: signup, restablecimiento de contraseña y refresh de token. Los usuarios normales llegan a estos puntos raramente, así que las comprobaciones añadidas molestan menos.

Antes de desafiar a alguien, registra señales que separen la automatización mala del comportamiento normal: picos de cuentas nuevas desde un rango de IP, intentos fallidos de login repetidos, refresh de token sin uso real de la API después, user agents inusuales, o tráfico que solo toca endpoints de lista/búsqueda.

Usa desafíos progresivos en vez de un baneo instantáneo. Empieza con un 429 claro y una pequeña cooldown. Si el patrón persiste, ralentiza al cliente y luego bloquea por un periodo corto (minutos, no días). Esto reduce la probabilidad de bloquear una Wi‑Fi de cafetería donde varios usuarios reales comparten una IP.

Trata el credential stuffing diferente de los picos generales. Para login, limita por identificador de cuenta más IP y usa umbrales más estrictos en intentos fallidos. Para tráfico API general, mantén límites más tolerantes y enfócate en patrones sostenidos y repetitivos.

Cuotas por usuario y reglas de uso justo

Los límites por minuto detienen picos, pero no responden a la pregunta de equidad: ¿quién consume más a lo largo del tiempo? Las cuotas por usuario (o por organización) limitan el uso total por día o mes, de modo que un cliente pesado no acapare silenciosamente todo.

Empieza con una unidad que la gente entienda: peticiones por día, tokens por mes o "jobs" por ciclo de facturación. En productos de equipo, las cuotas suelen pertenecer a la org con sub‑límites opcionales por usuario, así un compañero no quema toda la asignación.

Los límites blandos evitan fallos sorpresivos. Un patrón simple: notificar al 80%, advertir al 95% y bloquear al 100%. Incluso si aún no tienes facturación, esos umbrales ayudan a los clientes a ajustarse antes de fallar.

Cuando alguien supera la cuota, haz la respuesta obvia y accionable. Usa un estado claro (a menudo 429) e incluye uso actual, límite, tiempo de reinicio y cómo solicitar un aumento.

Un ejemplo concreto: si una app generada por IA se lanza sin cuotas, una clave de API filtrada puede generar una semana de uso en pocas horas. Equipos como FixMyMess ven esto después de un prototipo en vivo. Añadir topes mensuales a nivel de org más avisos tempranos suele detener el daño sin bloquear a clientes legítimos que simplemente necesitan un plan superior o un impulso temporal.

Dónde viven los límites: elecciones de arquitectura que aguantan en producción

Dónde haces cumplir los límites importa tanto como los números que eliges. La misma regla puede ser confiable o inútil según dónde viva el contador y cómo se actualice.

La mayoría de equipos imponen límites en uno de estos sitios:

• En memoria (por servidor): rápido y simple, pero falla con múltiples instancias
• Redis (cache compartida): una opción común, compartida entre instancias, soporta updates atómicos
• Base de datos: más fácil de auditar, pero suele ser lento y caro para checks por petición
• API gateway o funciones del CDN: excelente cuando está disponible, pero puede ser limitante para keys personalizadas y respuestas custom

Si no estás seguro, Redis más un pequeño wrapper en la app es un buen punto de partida para APIs públicas.

Realidades distribuidas y multi‑región

En sistemas distribuidos, las condiciones de carrera son un modo de falla silencioso. Dos peticiones pueden pasar la comprobación al mismo tiempo a menos que tu incremento‑y‑compara sea atómico. Usa incrementos atómicos (o un script/transaction único) y mantén claves consistentes, por ejemplo userId + route + time window. Claves inconsistentes crean agujeros que los abusadores encuentran rápido.

El tráfico multi‑región fuerza un trade‑off entre aplicación estricta y disponibilidad. Límites globales estrictos requieren un contador compartido o coordinación fuerte, lo que añade latencia y puede fallar cerrado. Muchos equipos aceptan límites suaves por región (consistencia eventual) porque mantiene la API responsiva y aun así detiene la mayoría del abuso.

Evita golpear tu BD principal solo para decidir permitir una petición. La limitación de tasa debe ser una búsqueda rápida, y tu lógica de negocio debe ejecutarse solo si la petición está permitida.

Si heredas un backend generado por IA (común con herramientas como Replit o v0), aquí es donde suele fallar: los límites están en proceso, se reinician en deploy y fallan en cuanto escalas.

Errores comunes y trampas

La mayoría de implementaciones fallidas no son culpa de atacantes sofisticados. Ocurren porque los límites son demasiado simples, contundentes o invisibles una vez desplegados.

Una trampa común es poner un único límite global y darlo por terminado. Parece seguro, pero castiga a tus mejores clientes (power users, partners) y a tus propias herramientas internas. Separa clases de tráfico (público, autenticado, partner, interno) y dales techos distintos.

Otra trampa es confiar solo en IP. Las IPs se comparten y rotan. Si bloqueas por IP solo, bloquearás a gente inocente y aun así fallarás contra bots distribuidos.

Vigila las tormentas de reintento. Un cliente recibe 429, reintenta de inmediato, vuelve a recibirlo y multiplica el tráfico en el peor momento. Tu respuesta 429 debe hacer que el backoff sea la elección obvia.

También vigila la auto‑limitación: tu frontend llama a la API durante un lanzamiento mientras jobs en segundo plano también la llaman para sincronizar datos. Si comparten la misma key o token, se pueden limitar entre sí y crear fallos aleatorios.

No viajes a ciegas. Si no ves qué usuarios, keys, rangos de IP o endpoints disparan los throttles, no podrás afinar reglas antes de que los clientes se quejen.

Lista rápida antes de lanzar

Antes de activar límites para todos, haz un repaso rápido en los puntos que suelen causar problemas:

• Separa el tráfico al menos en dos cubos: anónimo (mayor riesgo) y autenticado (más identificable).
• Haz los endpoints sensibles más estrictos que las lecturas normales: flujos de auth, restablecimiento, refresh de token, signup y rutas de búsqueda/report/export costosas.
• Haz las respuestas 429 claras: lenguaje simple más Retry-After para que los clientes bien comportados retrocedan.
• Añade monitorización antes del lanzamiento: principales infractores (key/IP/user) y endpoints más bloqueados.
• Planea excepciones: soporte necesita un camino seguro y temporal para sobrepasar límites con logging.

Escenario de ejemplo: detener scraping sin bloquear clientes reales

Tienes un endpoint público de búsqueda como GET /search?q=.... Funciona hasta que un scraper empieza a paginar todas las combinaciones de palabras clave y filtros todo el día. Los clientes reales siguen usando el sitio, pero ahora tu API pasa la mayor parte del tiempo respondiendo peticiones automatizadas. La latencia sube y también tu factura de BD.

Una política que suele funcionar mezcla control de ráfagas (para atrapar picos), un tope sostenido (para equidad) y mayor coste para endpoints fáciles de abusar.

Una configuración práctica:

• Ráfaga por IP: permite 30 peticiones por 10 segundos por IP, luego devuelve 429 para una pequeña cooldown
• Límite constante por usuario: permite 120 peticiones por minuto por usuario autenticado (claveada por user ID, no por IP)
• Guardia de paginación en búsqueda: limita la profundidad (por ejemplo, no más de página 20) a menos que el usuario esté verificado
• Coste de export: trata POST /export como 10x el coste de una búsqueda normal
• Usuarios anónimos: límites más bajos y requiere un pequeño delay tras 429 repetidos

Los usuarios normales rara vez notan esto. Buscan, hacen clic y quizá refrescan una vez. El scraper golpea el techo de ráfaga rápido y luego encuentra topes sostenidos cuando intenta seguir.

La primera semana, observa si los límites afectan a personas reales más de lo que ralentizan bots. Rastrea falsos positivos (quién alcanzó 429 y dónde), latencia (p95 antes/después), cambios en 401/403/429 y 5xx downstream, tickets de soporte desde redes compartidas y ofensores repetidos a lo largo del tiempo.

Si esto corre sobre un backend heredado generado por IA, ten cuidado: auth desordenada e IDs inconsistentes pueden hacer que las cuotas por usuario no sean fiables. Arregla identidad y logging primero, luego aprieta límites.

Próximos pasos y cuándo pedir ayuda

Empieza por las rutas de mayor riesgo y coste: flujos de autenticación (login, restablecimiento, refresh de token) y endpoints costosos (búsqueda, exports, llamadas AI, reportes). Despliega cambios en pasos pequeños para no sorprender a usuarios reales. Mide qué es lo "normal" y luego aprieta con el tiempo.

Un orden de despliegue que suele ser seguro:

• Solo logs: registra bloqueos potenciales, pero no bloquees todavía
• Límites blandos: devuelve advertencias o añade delay para usuarios pesados
• Aplicación: devuelve 429 claros con ventanas de reintento consistentes
• Ajuste: sube límites para clientes buenos conocidos, baja para automatización obvia

Escribe las reglas en lenguaje simple: qué está limitado, la ventana (por segundo/minuto/día), qué pasa cuando se alcanza el límite y cómo solicitar más cuota.

Pide ayuda cuando los límites sean fáciles de eludir, usuarios legítimos queden bloqueados y no puedas explicarlo desde los logs, la auth y las keys estén desordenadas (tokens compartidos, faltan user IDs), o sospeches problemas de seguridad mayores (secretos expuestos, inyecciones, checks de acceso rotos).

Si tu API empezó como un prototipo generado por IA y el throttling o la auth parecen frágiles, una remediación enfocada suele ser más rápida que parches sin fin. FixMyMess (fixmymess.ai) puede ejecutar una auditoría de código gratuita y luego ayudar a reparar la limitación de tasa, autenticación y endurecimiento de seguridad para dejar el proyecto listo para producción, típicamente en 48–72 horas.