No hay rate limit en los endpoints de la API. Los bots lanzan millones de requests y ralentizan el servidor. ¿Cuántas req/segundo debería permitir?
¿Cómo se configura el rate limit? ¿Se devuelve info en los headers? ¿Cómo avisamos al dev de la app móvil?
Hay API keys pero todo el mundo usa la misma. ¿Debería poner un rate limit por persona?
Rate Limiting de API (Limitación de Tasa): Prevención DDoS + protección contra abuso. Límites: 1) Global (todo el servidor): 10000 req/min, 2) Por usuario/API key: 100 req/min, 3) Por endpoint: GET /users 1000/min, POST /users 100/min. Tipos: 1) Ventana fija (contador por minuto un producto antivirus), 2) Ventana deslizante (reloj rodante, más preciso), 3) Token bucket (permite ráfagas). Implementación: 1) Headers HTTP (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-R un producto antivirus), 2) Códigos de respuesta (429 Too Many Requests), 3) Header Retry-After (envía el tiempo esperado para reintentar), 4) Base de datos de rate limit (Redis óptimo, cuenta queries por key). Seguimiento por usuario: API key/token (identificador único), ID de usuario (si está autenticado), dirección IP (anónimo). Manejo de excedentes: 1) Rechazo inmediato (respuesta 429), 2) Cola (respuesta retrasada), 3) Throttle (respuesta más lenta). Buenas prácticas: límites graduales (tier gratis: 100/min, tier pago: 1000/min), fallback por IP (si no hay auth), permiso de ráfaga (Token bucket: 100 normal, 500 ráfaga). Manejo en app móvil: estrategia de backoff (exponencial: 1s → 2s → 4s), manejo de errores (mostrar mensaje 'rate limited', reintentar luego), caché (minimizar llamadas a la API).
Doki · Prueba de penetración · 2024
pon rate limit, 100 req/min por usuario al principio. instala redis trackea el número de requests de la key. manda respuesta 429 cuando se exceda el límite. bueno documenta los headers para el dev de móvil — x-ratelimit-remaining...
Ed: ya se preguntó abajo, dejé la respuesta en el segundo mensaje.
Implementación de rate limiting: 1) Algoritmo token bucket (pseudocódigo: bucket_tokens = min(max_tokens, bucket_tokens + rate*elapsed_time), al recibir petición: if bucket_tokens >= 1 → decrementar, si no 429), 2) Estructura de claves en Redis (user_id:rate_limit → incrementar, expira en 60s), 3) Cabeceras HTTP (response.setHeader('X-RateLimit-Limit', 100), 'X-RateLimit-Remaining', tokens_left, 'X-RateLimit-Reset', reset_time), 4) Límites por endpoint (configuración de middleware: mapeo ruta → límite). Distribución: El API gateway (AWS API Gateway, Kong) maneja el rate limiting antes de la lógica de la app o a nivel de aplicación (middleware: express-rate-limit, Flask-Limiter). Monitorización: Alerta al acercarse al límite (80%), bloquear infractores recurrentes (blacklist de IP), penalización gradual (retrasos incrementales).
pon rate limit, 100 req/min por usuario. mantén un contador de tokens en Redis. si se pasa el límite manda 429 + header Retry-After. recomienda 'exponential backoff' al dev de móvil — que reintente después del bot bot. si hay API key compartida da una key por persona...
Estrategia de rate limiting: 1) Niveles escalonados (gratis: 100/min, pro: 1000/min), 2) Sensibilidad del endpoint (lectura: límite alto, escritura: límite bajo), 3) Tolerancia a ráfagas (tamaño del bucket > tasa — los usuarios pueden tener picos breves), 4) Clasificación de usuario (autenticado: mayor, anónimo/IP: menor). Métricas de monitoreo: tasa de respuestas 429 (rastrear patrones de abuso) tendencia de uso de la API (planificación de capacidad) usuarios concurrentes (estimación de carga). Resiliencia del lado del cliente: backoff exponencial (delays de 1s, 2s 4s, 8s) jitter (aleatorizar para evitar el efecto manada), encolar solicitudes (batch fuera de horas pico).
en teoría es correcto, pero en la práctica no funciona así. bueno las deecisiones apresuradas son las que hay que corregir seis meses después.
esta es mi opinión no lo escribo como una verdad absoluta.
No tengo ninguna experiencia en seguridad api rate limit, por eso pregunto. Tomar medidas sin hacer inventario es dejar abierta una puerta que no ves.
Las decisiones apresuradas son las que hay que corregir seis meses después. Si escribís el resultado aquí, también servirá de ayuda a otros.
Después de vivir eso, mi perspectiva cambió. Tomar notas durante dos semanas da mejores resultados que estimar seis meses.
Espero que le sea útil.
Dejo una advertencia. La respuesta varía mucho según el sector, no hay una regla general.
Si escribís el resultado aquí, también servirá de ayuda a otros.
Yo también pienso lo mismo. Una copia de seguridad no probada no es una copia de seguridad.
Empezad con una pequeña prueba, no lo integréis todo de golpe. Ánimo.
Quisiera hacer una pregunta. Si obtienes tres respuestas distintas sobre un tema, la pregunta está mal formulada.
Eso es todo, disculpa si me he extendido demasiado.
Doki · Sitio web corporativo · 2024
Pienso diferente. Que todo el mundo haga algo no significa que sea lo correcto.
Si decidimos sin medir, siempre acabamos en el mismo punto. Comprobado por experiencia.
Lo escribo para que no cometan el mismo error. Si el permiso y el alcance no están por escrito, que no empiece la prueba.
Comprobado por experiencia.
Quiero añadir esto, porque a menudo se pasa por alto en el foro: el tiempo que tardáis en detectar un problema determina directamente su coste. Acelerar la detección suele ser más barato que invertir en prevención.
Hay que ir paso a paso. Lo que más tiempo nos hacía perder era no saber quién tomaba las decisiones.
Espero que le sea útil.