TL;DR : Les points clés
  • Le rate limiting est nécessaire mais insuffisant seul contre les bots distribués
  • Analysez les en-têtes HTTP : un bot laisse souvent des empreintes facilement détectables
  • Implémentez une analyse comportementale sur les séquences de requêtes
  • Utilisez des token JWT avec rotation et détection de replay
  • Loggez tout et mettez en place des alertes sur les anomalies de trafic

Pourquoi votre API est une cible de choix

Contrairement à un site web, une API REST répond de façon structurée et prévisible. Elle renvoie des données JSON propres, sans publicités ni CAPTCHA. Pour un attaquant, c'est le paradis : pas d'interface graphique à contourner, des réponses exploitables directement, et des erreurs explicites qui guident l'exploration.

Les attaques les plus courantes contre les APIs sont le scraping de données (extraction massive de contenu), le credential stuffing (test de listes de logins/mots de passe volés), l'enumeration (parcours de ressources pour découvrir des données non liées), et les attaques DDoS ciblées sur des endpoints coûteux en calcul.

Chiffre clé : En 2026, plus de 47% du trafic Internet mondial est généré par des bots. Sur les APIs exposées sans protection, ce ratio monte souvent au-delà de 70 % : la majorité de vos ressources serveur servent des robots, pas vos utilisateurs.

1. Rate limiting : la première ligne de défense

Le rate limiting consiste à limiter le nombre de requêtes qu'une entité peut effectuer dans un intervalle de temps donné. C'est la protection de base, rapide à mettre en place.

Par IP

La stratégie la plus simple. En Node.js avec Express :

const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,  // 15 minutes
  max: 100,                   // 100 requêtes par IP
  standardHeaders: true,
  legacyHeaders: false,
  message: {
    error: 'Trop de requêtes, réessayez dans 15 minutes.'
  }
});

app.use('/api/', limiter);

Par utilisateur authentifié

Plus précis : on limite par token/session plutôt que par IP, ce qui évite de pénaliser les utilisateurs légitimes derrière un NAT ou un VPN partagé.

const limiter = rateLimit({
  windowMs: 60 * 1000,        // 1 minute
  max: 30,
  keyGenerator: (req) => {
    // Utiliser le user ID si authentifié, sinon l'IP
    return req.user.id || req.ip;
  }
});

Limite du rate limiting : Un bot sophistiqué peut distribuer ses requêtes sur des milliers d'IPs différentes (botnet) et respecter délibérément vos limites. Il faut donc l'associer à d'autres techniques.

2. Fingerprinting des en-têtes HTTP

Un navigateur web envoie des dizaines d'en-têtes HTTP cohérents entre eux. Un bot, lui, en envoie souvent trop peu, ou des combinaisons impossibles pour un vrai navigateur. Analyser ces empreintes permet de détecter les bots sans impacter l'expérience utilisateur.

Signaux révélateurs d'un bot

  • User-Agent absent ou générique : python-requests/2.28, curl/7.88, ou complètement absent
  • Accept-Language manquant : un vrai navigateur envoie toujours la langue de l'utilisateur
  • Accept-Encoding cohérent mais faux : certains bots copient les en-têtes d'un vrai navigateur mais oublient de compresser les échanges
  • Referer suspect ou absent : sur une API publique, les requêtes sans Referer depuis un navigateur sont rares
  • Timing parfaitement régulier : un humain ne clique jamais exactement toutes les 500 ms
function detectBotSignals(req) {
  const signals = [];
  const ua = req.headers['user-agent'] || '';

  // User-agent absent ou bot connu
  if (!ua) signals.push('no_user_agent');
  if (/python|curl|wget|scrapy|httpx/i.test(ua)) signals.push('known_bot_ua');

  // En-têtes suspicieusement absents
  if (!req.headers['accept-language']) signals.push('no_accept_language');
  if (!req.headers['accept']) signals.push('no_accept');

  // Score de confiance
  const score = signals.length;
  return { isSuspect: score >= 2, signals, score };
}

3. Analyse comportementale des séquences

C'est la technique la plus efficace contre les bots avancés qui imitent les navigateurs. Un humain navigue de façon imprévisible : il consulte un produit, revient en arrière, cherche autre chose. Un bot suit un pattern répétitif et prévisible.

Ce qu'il faut monitorer

  • Séquences répétitives : les mêmes endpoints dans le même ordre, encore et encore
  • Vitesse entre les requêtes : un humain a un temps de réaction minimum de ~200 ms
  • Ratio lecture/écriture anormal : un scraper ne fait que des GET, jamais de POST
  • Accès à des ressources inexistantes : un bot qui énumère teste des IDs séquentiels et génère des 404 en série
// Exemple simplifié de détection d'enumeration
const suspiciousPatterns = new Map();

app.use('/api/users/:id', (req, res, next) => {
  const ip = req.ip;
  const key = `enum_${ip}`;
  const now = Date.now();

  if (!suspiciousPatterns.has(key)) {
    suspiciousPatterns.set(key, { count: 0, lastSeen: now, ids: [] });
  }

  const pattern = suspiciousPatterns.get(key);

  // Si l'IP fait plus de 20 requêtes sur des IDs différents en 60s
  if (pattern.count > 20 && (now - pattern.lastSeen) < 60000) {
    return res.status(429).json({ error: 'Comportement suspect détecté.' });
  }

  pattern.count++;
  pattern.lastSeen = now;
  pattern.ids.push(req.params.id);
  next();
});

4. Tokens et protection des endpoints sensibles

Pour les endpoints d'authentification (login, register, password reset), les bots de credential stuffing sont particulièrement dangereux. Ils testent des millions de combinaisons email/mot de passe issues de fuites de données.

Mesures spécifiques pour l'authentification

  • CAPTCHA invisible sur les endpoints sensibles : reCAPTCHA v3 ou hCaptcha sans friction pour l'utilisateur
  • Verrouillage progressif : après N échecs, délai exponentiel avant la prochaine tentative
  • Alertes sur les pics de 401/403 : une soudaine vague d'échecs d'auth = signal d'alerte
  • Have I Been Pwned integration : refuser les mots de passe présents dans les fuites connues
# Nginx : limiter les tentatives de login
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location /api/auth/login {
  limit_req zone=login burst=3 nodelay;
  limit_req_status 429;
  proxy_pass http://backend;
}

5. Monitoring et alertes temps réel

Sans visibilité sur ce qui se passe sur votre API, vous ne saurez jamais qu'une attaque est en cours. Un bot patient peut exfiltrer des données pendant des semaines si personne ne surveille les logs.

Métriques à surveiller absolument

  • Taux de réponses 4xx par IP et par endpoint
  • Volume de requêtes par minute par endpoint (alerter sur les pics)
  • Distribution des User-Agents (alerter si un UA inconnu représente >5% du trafic)
  • Temps de réponse moyen (une attaque volumétrique dégrade les performances)
  • Géolocalisation des IPs (pic soudain depuis un pays inhabituel)

CyberGuard surveille votre API en temps réel

Plutôt que d'implémenter et maintenir ces protections vous-même, CyberGuard les applique automatiquement sur vos endpoints. Détection comportementale, blocage des bots connus, alertes en temps réel — sans modifier une ligne de votre code.

Essayer gratuitement 15 jours

Conclusion

La protection d'une API contre les bots est un problème multicouche. Aucune technique seule ne suffit : le rate limiting bloque les attaques volumétriques, le fingerprinting filtre les bots peu sophistiqués, et l'analyse comportementale détecte les attaquants patients. Combinez-les, loggez tout, et mettez en place des alertes pour réagir vite.