Rate limiting par adresse IP : concevoir des limites adaptées aux environnements d’IP partagées

Le rate limiting est un mécanisme de défense essentiel pour protéger les applications web et les API contre les abus, l’épuisement des ressources et les attaques par déni de service. L’approche la plus simple — et la plus répandue — consiste à compter les requêtes par adresse IP. Mais cette méthode atteint vite ses limites face à une réalité réseau désormais omniprésente : les adresses IP partagées.

On les retrouve partout : NAT d’entreprise, réseaux d’opérateurs mobiles, Wi-Fi public, VPN, proxies ou encore nœuds de sortie TOR. S’appuyer uniquement sur l’IP source pour identifier un utilisateur ou une entité unique conduit presque inévitablement à deux écueils : bloquer des utilisateurs légitimes, avec des faux positifs, ou laisser des attaquants plus aguerris contourner les seuils en faisant tourner des pools d’IP partagées, avec des faux négatifs.

Cet article présente plusieurs approches pour concevoir des limites de débit plus résistantes aux environnements d’IP partagées, au-delà d’un simple comptage par adresse /32 ou /128.

The Core Problem: IP Address != User

Historiquement, une adresse IP correspondait souvent à un utilisateur unique, ou à un petit groupe d’utilisateurs derrière un NAT statique. Aujourd’hui, cette hypothèse ne tient plus :

• Mobile Carriers: Des milliers, voire des dizaines de milliers d’utilisateurs, peuvent partager une même adresse IPv4 publique via du Carrier-Grade NAT (CGNAT).
• Enterprise Networks: Les grandes organisations font souvent transiter tout leur trafic sortant par un nombre limité d’adresses IP publiques.
• Public Wi-Fi/Hotspots: De nombreux utilisateurs se connectent simultanément derrière une seule IP de passerelle.
• Proxies, VPNs, TOR: Ces services regroupent volontairement plusieurs utilisateurs derrière des IP partagées, pour des raisons de confidentialité ou de contournement. Les attaquants s’en servent aussi pour masquer leur identité et répartir leur charge sur de nombreuses IP.
• Cloud Providers/Data Centers: Les charges de travail hébergées dans le cloud ou en data center proviennent souvent de larges plages d’IP bien connues, partagées entre de nombreux clients.

Lorsqu’un grand nombre d’utilisateurs légitimes partagent la même IP, une limite simple par IP se déclenche rapidement et finit par bloquer tout le monde. À l’inverse, un attaquant peut faire tourner un ensemble d’IP de proxy : chacune reste apparemment sous le seuil, mais l’ensemble dépasse largement la limite que l’on voulait imposer.

Beyond Simple IP: Augmenting Rate Limiting Signals

Pour construire des limites plus fiables, il faut enrichir le signal au-delà de la seule IP source immédiate.

1. User-Centric Identifiers

Lorsque c’est possible et pertinent, associez les limites de débit à un identifiant utilisateur plutôt qu’à la seule adresse IP. C’est l’approche la plus adaptée pour les actions authentifiées.

• Session ID/Cookie: Suivre les requêtes par session permet de repérer les actions répétées provenant du même navigateur ou du même appareil, même lorsque l’adresse IP est partagée.