Y'a pas de rate limit sur les endpoints de l'API. Les bots envoient des millions de requêtes et ralentissent le serveur. Combien de requêtes/sec on devrait autoriser ?
Comment configurer le rate limit ? On renvoie l'info dans les headers ? Comment on prévient les devs de l'app mobile ?
On a des clés API, mais tout le monde utilise la même. Je devrais mettre un rate limit par personne ?
API Rate Limiting (Limitation de débit) : prévention DDoS + protection contre les abus. Limites : 1) Globale (serveur entier) : 10000 req/min, 2) Par utilisateur/clé API : 100 req/min, 3) Par endpoint : GET /users 1000/min, POST /users 100/min. Types : 1) Fenêtre fixe (compteur par minute), 2) Fenêtre glissante (horloge roulante, plus précis), 3) Seau de jetons (autorisation de rafale). Implémentation : 1) Headers HTTP (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset), 2) Codes de réponse (429 Too Many Requests), 3) Header Retry-After (envoyer le temps d'attente attendu), 4) Base de données de rate limit (Redis optimal, comptage des requêtes par clé). Suivi par utilisateur : clé API/token (identifiant unique), ID utilisateur (si authentifié), adresse IP (anonyme). Gestion du dépassement : 1) Rejet immédiat (réponse 429), 2) File d'attente (réponse différée), 3) Étranglement (réponse plus lente). Meilleures pratiques : limites graduées (offre gratuite : 100/min, offre payante : 1000/min), fallback basé sur l'IP (si pas d'auth), autorisation de rafale (seau de jetons : 100 normal, 500 rafale). Gestion app mobile : stratégie de backoff (exponentielle : 1s → 2s → 4s), gestion d'erreurs (afficher le message 'rate limited', réessayer plus tard), mise en cache (minimiser les appels API).
Doki · Test d'intrusion · 2024
mets un rate limit, 100 req/min par utilisateur au début. installe redis track le nombre de requêtes par clé... envoie une réponse 429 quand la limite est dépassée. documente les headers pour le dev mobile — x-ratelimit-remaining...
PS : c'est demandé plus bas, j'ai répondu dans le deuxième message.
Implémentation du rate limiting : 1) Algorithme du seau à jetons (pseudocode : bucket_tokens = min(max_tokens, bucket_tokens + rate*elapsed_time), à l'arrivée d'une requête : si bucket_tokens >= 1 → décrémenter, sinon 429), 2) Structure de clé Redis (user_id:rate_limit → incrémenter, expiration 60s), 3) En-têtes HTTP (response.setHeader('X-RateLimit-Limit', 100), 'X-RateLimit-Remaining', tokens_left, 'X-RateLimit-Reset', reset_time), 4) Limites par endpoint (config middleware : mapping route → limite). Déploiement : la passerelle API (AWS API Gateway, Kong) gère le rate limiting avant la logique applicative ou au niveau applicatif (middleware : express-rate-limit, Flask-Limiter). Monitoring : alerte à l'approche de la limite (80%), blocage des récidivistes (blacklist IP), pénalités progressives (délais croissants).
mets un rate limit, 100 req/min par utilisateur... garde un compteur de jetons dans Redis. si la limite est dépassée, envoie un 429 + header Retry-After. conseille le 'backoff exponentiel' au dev mobile — réessayer arpès un bot bot. si vous avez une clé API partagée donnez une clé par personne...
Stratégie de rate limiting : 1) Paliers progressifs (gratuit : 100/min, pro : 1000/min), 2) Sensibilité des endpoints (lecture : limite haute, écriture : limite basse), 3) Tolérance aux pics (taille du bucket > débit — les utilisateurs peuvent avoir des pics brefs), 4) Classification des utilisateurs (authentifiés : plus élevé anonymes/IP : plus bas). Métriques de monitoring : taux de réponses 429 (suivre les patterns d'abus) tendance d'utilisation API (planification capacité) utilisateurs concurrents (estimation charge). Résilience côté client : backoff exponentiel (délais 1s, 2s, 4s, 8s), jitter (randomiser pour éviter l'effet troupeau), mise en file d'attente des requêtes (batch hors pointe).
c'est vrai en théorie, mais ça ne marche pas ainsi en pratique. les décisions hâtives finissent par être corrigées six mois plus tard.
c'est mon avis je ne l'écris pas comme une vérité absolue.
Je n'ai aucune expérience en sécurité api rate limit, c'est pourquoi je pose la question. Prendre une mesure sans faire d'inventaire, c'est laisser une porte ouverte sans le savoir.
Les décisions hâtives finissent par être corrigées six mois plus tard. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.
Mon regard a changé après avoir vécu cela. Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois.
J'espère que cela vous sera utile.
Je me permets une petite mise en garde. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.
Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.
Je suis du même avis. Une sauvegarde non testée n'est pas une sauvegarde.
Commencez par un petit test, ne vous engagez pas sur tout d'un coup. Bon courage.
J'aimerais poser une question. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.
Voilà, désolé si je me suis étendu.
Doki · Site web d'entreprise · 2024
Je pense différemment. Ce que tout le monde fait ne signifie pas que c'est la bonne chose.
Quand on décide sans mesurer, on revient toujours au même point. C'est confirmé par l'expérience.
J'écris cela pour éviter que vous ne fassiez la même erreur. Si l'autorisation et le périmètre ne sont pas écrits, ne lancez pas ce test.
C'est confirmé par l'expérience.
J'aimerais ajouter ceci, car c'est souvent oublié sur le forum : le temps que vous mettez à détecter un problème détermine directement son coût. Accélérer la détection est souvent moins coûteux que d'investir dans la prévention.
Il faut y aller étape par étape. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.
J'espère que cela vous sera utile.