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 500ms
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 ~200ms
  • Ratio lecture/?criture anormal ? un scraper ne fait que des GET, jamais de POST
  • Acc?s ? des ressources inexistantes ? un bot qui enum?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.