Transport Sécurité IA Gestion des bots API Shield

La protection web était en place. Les attaquants ont pivoté vers l'API de l'app mobile.

Compagnie aérienne internationale de taille moyenne · Canal web entièrement couvert par Cloudflare WAF, Turnstile et Bot Management : trafic sain, conversion normale. L'attaque s'est déplacée vers l'API de l'app iOS / Android native, là où un CAPTCHA ne peut pas tourner sans casser l'expérience utilisateur.

Anonymisé Canal app mobile uniquement 5 min read
BS Bot Shield by Brixio
Durée du pilote4 semainesMode LOG, observation seule, aucun impact trafic
Signaux de détection14Signaux personnalisés, calés sur le funnel app mobile
Faux positifs0Clients mobiles du marché domestique protégés tout au long du pilote
Coût infrastructureFree tierResté sur le free tier Cloudflare pendant tout le pilote
Contexte

Le funnel de réservation web était déjà une cible difficile : WAF Cloudflare, Turnstile sur chaque soumission de formulaire et Bot Management sur chaque requête. La conversion y semblait normale. Mais la compagnie observait toujours une pression sur l'inventaire de certaines routes (des sièges bloqués, jamais payés) et des analyses qui ne correspondaient plus à la demande réelle. Le trafic arrivait par l'API de l'application mobile native, là où Turnstile ne peut pas tourner sans casser l'UX iOS/Android, et où les attaquants peuvent usurper l'empreinte TLS de l'application légitime. Bot Shield y a été déployé en mode observation seule pour trancher la question.

Pourquoi le WAF ne peut pas le détecter : l'abus se passe sur l'API de l'app mobile.

Sur le web, Turnstile bloque le funnel de réservation et le trafic paraît propre. Sur le canal app mobile, il n'y a pas de CAPTCHA pour filtrer, donc un vrai client suit simplement recherche → réservation temporaire → informations passager → paiement. Les bots distribués n'amorcent que la deuxième étape sur les mêmes endpoints mobiles, et ne la terminent jamais.

Animation 1

Funnel de réservation : vrai client vs. nuée de bots distribués

LIVE
ÉTAPE 1
Recherche
GET /search
ÉTAPE 2 · CIBLE BOT
Réservation temporaire
POST /tempBooking · blocage 8 min
ÉTAPE 3
Détails passager
POST /passenger
ÉTAPE 4
Paiement confirmé
POST /pay → ✓
Vrai client · 1 session toutes les ~6 min
Recherche, bloque un siège, saisit les informations passager, paye. Atteint l'étape 4.
✓
✓
✓
$
Attaquants distribués · des centaines par heure
Chaque tentative arrive d'une nouvelle IP, d'un ASN et d'un User-Agent différents. Lance GET /search, puis POST /tempBooking, puis abandonne, sans jamais atteindre les détails passager ni le paiement.
0
tentatives · dernière heure
✓
✓
Ce que voit le WAF : une requête parfaitement valide vers l'app mobile : le bon user-agent, l'empreinte TLS légitime de l'app Android, une IP résidentielle dans un pays plausible, et un appel POST /tempBooking propre. Aucun CAPTCHA n'a jamais été demandé ; le canal mobile n'en a pas. Ce que voit Bot Shield : la même session ne revient jamais, la même empreinte JA3/JA4 frappe depuis quarante autres IP en moins d'une minute, et le taux de conversion du funnel pour cette empreinte est exactement zéro.

Le coût se matérialise en aval : en inventaire bloqué et en tarifs gonflés.

Chaque réservation temporaire immobilise un siège pendant plusieurs minutes. Les systèmes de yield management traitent les sièges bloqués comme pris et relèvent discrètement le tarif affiché. Les vrais clients paient le tarif gonflé ou renoncent.

Animation 2

Un vol · sièges & tarif à mesure que le botnet bloque l'inventaire

LIVE
VOL XX-1408 · 60 SIÈGES
Tarif publié le plus bas
€129
▲ €0 (vs. référence)
État de l'inventaire
Disponible60
Réservé (réel)0
Bloqué par bots0
Évolution du tarif
Ce que vous voyez dans cette scène : les vrais clients (vert) arrivent lentement et régulièrement. Les bots (rose) bloquent des sièges par vagues ; chaque blocage expire après la fenêtre de grâce de la compagnie, mais le tarif affiché a déjà grimpé entre-temps. Le transporteur voit les prix augmenter et la conversion baisser ; le revenue management voit une demande qui n'existe pas réellement.
Le défi

Ce que Bot Shield a mis en évidence sur l'API de l'app mobile.

  • Pivot de canal : le funnel web était propre (WAF + Turnstile + Bot Management). Les mêmes acteurs se sont déplacés vers l'API de l'app mobile, là où aucun CAPTCHA ne peut être affiché.
  • Usurpation TLS de l'app mobile : les empreintes JA3/JA4 légitimes de l'app Android étaient rejouées depuis des outils desktop sur des ASNs hors réseau, faisant paraître les requêtes comme du trafic applicatif authentique.
  • Rotation de proxies résidentiels : les sessions d'un même attaquant semblaient provenir de dizaines d'ASN grand public, contournant les limites de débit par IP sur les endpoints mobiles.
  • Blocage de réservations temporaires : les bots appelaient tempBooking sur l'API mobile et utilisaient la fenêtre de grâce de la compagnie pour maintenir des sièges bloqués sans jamais payer.
  • Distorsion géographique : les géographies à faible conversion sur le canal mobile faussaient les tableaux de bord et les décisions de routage du revenue management.
L'approche

Comment Bot Shield a été déployé.

  • Canal app mobile uniquement : le canal web est resté sur sa stack Cloudflare existante. Bot Shield s'est positionné devant les endpoints API de l'app iOS/Android, là où Turnstile ne peut pas filtrer sans dégrader l'UX.
  • Pilote en mode LOG : quatre semaines de scoring observation seule pendant que les signaux étaient calés sur le trafic mobile réel de la compagnie.
  • Bibliothèque de signaux personnalisée : quatorze signaux de détection définis par route (search, tempBooking, passenger, payment) plutôt que des règles globales génériques.
  • Réputation JA3/JA4 : empreintes scorées par rapport au référentiel iOS/Android légitime, de sorte que le trafic applicatif usurpé depuis des ASNs desktop était signalé immédiatement.
  • Tolérance par canal : les grands voyageurs du marché domestique sur la vraie app mobile exemptés des signaux de volume et d'absence de paiement pour éviter les faux positifs.
  • Déploiement ENFORCE : seuils de blocage relevés progressivement après revue par les parties prenantes des preuves du mode LOG.
Résultats du pilote en mode LOG

Ce qui a changé une fois Bot Shield activé.

Signaux
14 signaux de détection calés sur le funnel.
Familles de bots
Identifiées par réputation d'empreintes JA3/JA4.
Faux positifs
Éliminés pour les clients mobiles du marché domestique.
Coût infra
Resté sur le free tier Cloudflare pendant tout le pilote.

Trois vues radar du tableau de bord en mode LOG rendent le schéma d'abus impossible à ignorer. La forme de la dernière heure déborde au-delà du référentiel 7 jours sur les axes qui comptent : une toute nouvelle empreinte, un pays jamais vu, et un unique signal d'attaque à son maximum.

Profil d'empreintes
JA3/JA4 : nouvelles combinaisons
NOUVEAU
Labels rouges : combinaisons JA3/JA4 vues dans la dernière heure mais absentes des 7 derniers jours. Chacune est une toute nouvelle empreinte frappant tempBooking.
Profil géographique
Pays : nouveaux & sans paiement
NOUVEAU
VN domine le classement de la dernière heure avec du trafic jamais vu dans les 7 jours précédents ; sa forme 7 j est quasiment nulle. Les autres pays en rouge paient sous le seuil de 10 % de conversion.
Vecteurs d'attaque
Distribution des clusters de signaux
HAUSSE
geo_surge est à son maximum sur le ring 1h : presque toutes les sessions signalées dans la dernière heure ont déclenché ce signal. Le référentiel 7 j pour le même signal représente un tiers de cela.

Comment lire ces graphiques : chaque axe représente une empreinte, un pays ou un signal. Les trois polygones colorés montrent quelle part du trafic signalé total cet axe représente sur 1 h, 24 h et 7 j. Quand la forme 1 h déborde largement au-delà de la forme 7 j sur un axe en rouge, vous observez le début d'une nouvelle attaque, généralement des minutes avant que le revenue management ne le remarque dans la conversion.

Résultat

De l'observation à l'enforcement.

Le schéma d'abus sur le canal app mobile a été documenté de bout en bout avec des preuves par session (signaux, empreintes, ASN, pays, chemin de requête), exportables en CSV pour l'équipe d'analystes de la compagnie. Bot Shield est passé en ENFORCE sur les routes app mobile les plus exposées (réservation temporaire et confirmation de paiement), avec une liste blanche définie par le client pour les partenaires de confiance et les IPs d'agrégateurs. Le canal web a conservé sa stack Cloudflare existante sans modification. Le tableau de bord sert désormais d'outil opérationnel quotidien pour les équipes de protection des revenus et de sécurité de la compagnie.

Engagement continu couvert par un plan Brixio Support / Managed Services : revues trimestrielles, mises à jour des signaux et whitelisting des empreintes lors des nouvelles versions de l'application.

Perspective sectorielle

Le scoring IA des bots est désormais la référence pour les API de voyage à forte valeur.

Les compagnies aériennes et les agences de voyage en ligne font face aux attaques bots les plus persistantes et sophistiquées de toutes les industries. L'abus de réservations temporaires, le credential stuffing sur les comptes fidélité et le scraping tarifaire sont trois familles de menaces distinctes qui partagent une même propriété : anodines isolément, elles distordent ensemble les prix, les décisions de revenue management et les analyses de conversion. L'approche LOG-mode-first de Bot Shield permet au transporteur de constituer une base de preuves avant toute décision de blocage, et la couche d'empreintes mobiles JA3/JA4 est ce qui rend le canal aérien actionnable sans CAPTCHA.

IATA NDC PCI DSS (couche API)
Sécurité IA & Bot ShieldIndustrie Transport & Mobilité
Protégez votre API de réservation

Vous observez des patterns similaires sur votre canal mobile ou API ?

Bot Shield se déploie en mode LOG d'abord : aucun impact trafic, aucune friction CAPTCHA. Quatre semaines d'observations avant toute décision de blocage.

Parler à Bot Shield Autres études de cas