Limitation des requêtes par agent utilisateur

Vous pouvez limiter le nombre de requêtes autorisées pour un agent utilisateur spécifique. L'exemple de règle suivant permet aux utilisateurs d'applications mobiles d'effectuer jusqu'à 100 requêtes toutes les 10 minutes. Vous pouvez également créer une règle distincte limitant le débit pour les navigateurs de bureau.

Autorisation d'adresses IP ou d'ASN spécifiques

Contrôlez l'accès en incluant ou en excluant certaines adresses IP ou certains numéros de système autonome (ASN) d'une règle de limitation de débit.

L'exemple de règle de limitation de débit suivant autorise jusqu'à 10 requêtes par minute provenant de la même adresse IP et effectuant une GET requête vers le /status chemin, à condition que l'adresse IP ne figure pas dans la liste d'adresses IP intitulée partner_ips.

Limitation des requêtes par référent

Vous pouvez limiter les requêtes provenant de pages référentes, telles que des publicités tierces ou des sites Web externes. Ce cas d'utilisation permet de réduire le risque d'attaques par déni de service indirect (DDoS DDoS ) et vous aide à gérer les quotas de requêtes.

Cette règle d'exemple nécessite la limitation avancée du débit.

Règle n° 1 : Seuil de protection initial

La règle 1 autorise jusqu'à quatre tentatives de connexion infructueuses par minute. Lorsque la limite est dépassée, le système déclenche un défi géré. Cette configuration aide les utilisateurs légitimes à se remettre d'erreurs de connexion occasionnelles tout en décourageant les robots automatisés.

Règle 2 : Seuil de protection intermédiaire

Si les utilisateurs légitimes réussissent le défi lorsqu'ils atteignent la limite de la règle 1, la règle 2 applique une protection supplémentaire pour les clients qui continuent à faire des tentatives de connexion infructueuses. Il autorise jusqu'à 10 tentatives infructueuses en 10 minutes avant de déclencher un nouveau défi géré.

Règle n° 3 : Seuil de protection strict

La règle 3 impose une sanction plus sévère aux clients qui dépassent le seuil fixé par la règle 2 en bloquant une adresse IP pendant une journée après 20 tentatives de connexion infructueuses en une heure. Cette règle offre une défense ultime contre les tentatives d'attaques persistantes.

Toutes ces règles d'exemple nécessitent un for Business ou supérieur.

Ces trois règles ont une expression de comptage distincte de l'expression de règle (également appelée expression d'atténuation). Lorsque vous configurez une expression de comptage distincte, les critères de correspondance sont utilisés lorsqu'une action est déclenchée. Dans l'expression de comptage, vous pouvez inclure des conditions basées sur le code HTTP d'état de réponse et les HTTP en-têtes de réponse afin d'intégrer la limitation de débit à votre logique backend.

Vous pouvez également choisir d'utiliser deux expressions différentes : une expression de comptage et une expression de règle/atténuation — pour définir :

1. Les requêtes utilisées pour calculer le taux.
2. Les demandes effectivement traitées.

Par exemple, l'exemple de la règle 3 calcule le taux en tenant compte POST des requêtes qui /login ont renvoyé un code 401 d'état 403HTTP ou. Cependant, lorsque la limite de débit est dépassée, CIS bloque toutes les requêtes vers example.com l'hôte générées par la même adresse IP.

Empêcher le scraping de contenu à l'aide d'une chaîne de requête

Dans cet exemple, les clients effectuent des opérations (telles que la recherche de prix ou l'ajout d'articles à un panier) sur un site Web de commerce électronique à l'aide de paramètres de chaîne de requête. Par exemple, une requête type envoyée par un client pourrait ressembler à ceci :

GET https://store.com/merchant?action=lookup_price&product_id=215
Cookie: session_id=12345

Votre équipe de sécurité pourrait envisager de limiter le nombre de fois qu'un client peut consulter les prix afin d'empêcher les robots, qui auraient pu échapper à la gestion CIS des robots, de récupérer l'intégralité du catalogue du magasin.

Ces deux règles de limitation de débit correspondent aux demandes effectuant une action sélectionnée (recherche de prix, dans cet exemple) et utilisent IP comme caractéristique de comptage. De manière similaire à l 'exemple /login, les deux règles permettent de réduire les faux positifs dans le cas de visiteurs persistants (mais légitimes).

Vous pouvez limiter la recherche d'un élément spécifique product_id à l'aide d'un paramètre de chaîne de requête. En ajoutant un paramètre de requête comme caractéristique de comptage, le taux est calculé pour toutes les requêtes, quel que soit le client.

L'exemple suivant limite le nombre de recherches pour chaque product_id à 50 requêtes en 10 secondes.

Cette règle d'exemple nécessite la limitation avancée du débit.

Vous pouvez suivre le même modèle de règles de limitation de débit pour protéger les applications qui gèrent les réservations.

Empêcher le scraping de contenu à l'aide du corps de la requête

Considérons une application qui gère l'opération et ses paramètres via le corps de la requête au format JSON. Par exemple, l'opération lookup_price pourrait se présenter comme suit :

POST https://api.store.com/merchant
Cookie: session_id=12345
Body:
{
  "action": "lookup_price",
  "product_id": 215
}

Dans ce scénario, vous pouvez créer une règle suivante pour limiter le nombre d'actions à partir de sessions individuelles :

Cette règle d'exemple nécessite la limitation avancée du débit et l'inspection de la charge utile.

Vous pouvez également limiter le nombre de recherches pour chaque, quel product_id que soit le client à l'origine des requêtes, en déployant une règle telle que celle-ci :

Cette règle d'exemple nécessite la limitation avancée du débit et l'inspection de la charge utile.

Si le corps de la requête n'est pas au format JSON, vous pouvez utiliser le http.request.body.raw champ et des expressions régulières (avec l 'opérateur matches) pour obtenir le même résultat.

Limiter les requêtes provenant de robots

Vous pouvez utiliser la limitation du débit pour contrôler le trafic automatisé provenant des robots. Une approche courante consiste à surveiller les requêtes qui renvoient un nombre élevé de codes d'état 403 de 404 réponse ou, qui indiquent souvent une activité de scraping automatisée.

Dans cette situation, vous pouvez configurer une règle similaire à celle-ci :

Cette règle d'exemple nécessite un forfait Business ou supérieur.

Pour contrôler la fréquence des actions effectuées par des sources automatisées, envisagez d'utiliser des règles de limitation de fréquence en association avec la gestion des bots. Avec Bot Management, vous pouvez utiliser le score des bots comme critère de correspondance afin d'appliquer la règle uniquement au trafic automatisé ou susceptible d'être automatisé. Par exemple, vous pouvez utiliser un score maximal (ou seuil) de 30 pour le trafic probablement automatisé et 10 pour le trafic automatisé.

Vous pouvez renforcer la protection en combinant la limitation du débit avec la gestion des bots. Avec Bot Management, vous pouvez utiliser le score des bots comme critère de correspondance afin d'appliquer la règle uniquement au trafic automatisé ou susceptible d'être automatisé.

Exemple :

• Un score inférieur à 30 indique probablement un trafic automatisé.
• Un score inférieur à 10 indique un trafic automatisé confirmé.

Protection des ressources

Même GET les requêtes peuvent solliciter l'application ou consommer de la bande passante lorsqu'elles sont utilisées pour des téléchargements de données volumineuses, telles que des fichiers ou des images.

Prenons par exemple le point final suivant :

GET https://api.store.com/files/<FILE_ID>
Header: x-api-key=9375

Pour empêcher les abus tout en autorisant les téléchargements légitimes, vous pouvez définir une règle qui limite les demandes de fichiers sans avoir à écrire des règles distinctes pour chaque fichier.

Cette règle d'exemple nécessite la limitation avancée du débit.

Cette règle limite les téléchargements à 10 requêtes toutes les 10 minutes par fichier sous https://api.store.com/files/*. En utilisant Path comme caractéristique de comptage, vous pouvez éviter de créer de nouvelles règles pour chaque nouveau <FILE_ID>. Le tarif est calculé par fichier, indépendamment de l'adresse IP du client ou de l'identifiant de session.

Vous pouvez renforcer davantage la protection en combinant Path avec un identifiant client tel que x-api-key ou IP. Cette approche vous permet de limiter le nombre de téléchargements qu'un client spécifique peut effectuer pour un fichier donné.

Cette règle d'exemple nécessite la limitation avancée du débit.

Limiter le nombre d'opérations

Pour limiter le taux d'actions, créez la règle suivante :

Cette règle d'exemple nécessite la limitation avancée du débit et l'inspection de la charge utile.

Limiter la complexité totale des requêtes

La complexité du traitement d'une GraphQL demande peut varier considérablement. Comme l'API utilise un seul point de terminaison, il peut être difficile de déterminer la complexité de chaque requête avant son traitement.

Pour éviter l'épuisement des ressources sur le serveur d'origine, limitez la complexité totale des requêtes par client au fil du temps, plutôt que de limiter le nombre de requêtes. CIS La limitation du débit vous permet de créer des règles qui suivent la complexité au fil du temps et bloquent les requêtes qui dépassent un budget de complexité défini.

Cette méthode nécessite que le serveur d'origine attribue un score de complexité à chaque requête et inclue ce score dans l'en-tête HTTP de réponse. Le mécanisme de limitation du débit utilise ensuite les informations relatives au score pour mettre à jour le budget de complexité pour ce client spécifique.

L'exemple suivant définit un budget de complexité total de 1 000 par heure :

Cette règle d'exemple nécessite la limitation avancée du débit et l'inspection de la charge utile.

Lorsque le serveur d'origine traite une requête, il ajoute un scoreHTTP en-tête à la réponse avec une valeur qui indique la quantité de travail effectuée par l'origine pour la traiter. Par exemple, 100. Au cours de l'heure suivante, le même client peut effectuer des demandes jusqu'à un budget supplémentaire de 900. Dès que ce budget est dépassé, les demandes ultérieures sont bloquées jusqu'à l'expiration du délai.

Limiter la complexité de chaque requête individuelle

Les clients API Shield peuvent utiliser la protection contre GraphQL les requêtes malveillantes pour protéger leurs GraphQL API. Cette fonctionnalité analyse le trafic GraphQL entrant à la recherche de requêtes susceptibles de surcharger le serveur d'origine et de provoquer un déni de service.

Vous pouvez créer des règles pour limiter la profondeur et la taille des requêtes GraphQL entrantes. Ces règles permettent de bloquer les requêtes suspectes ou excessivement complexes avant qu'elles n'affectent les performances.