Transport AI Security Bot Management API Shield

Web was locked down. The attackers pivoted to the mobile-app API.

Mid-size international airline · Web channel fully covered by Cloudflare WAF, Turnstile, and Bot Management, clean traffic, healthy conversion. The attack moved to the native iOS / Android app's API, where a CAPTCHA can't realistically run.

Anonymised Mobile-app channel only 5 min read
BS Bot Shield by Brixio
Pilot duration4 weeksLOG mode, observe-only, zero traffic impact
Detection signals14Custom signals tuned to the mobile-app funnel
False positives0Home-market mobile customers protected throughout
Infrastructure costFree tierStayed on Cloudflare free tier through the pilot
Context

The web booking funnel was already a hard target: Cloudflare WAF, Turnstile on every form submission, and Bot Management scoring on every request. Conversion there looked normal. But the carrier still saw inventory pressure on certain routes (seats held, never paid) and analytics that no longer matched real demand. The traffic was coming through the native mobile-app API, where Turnstile can't run without breaking the iOS / Android UX, and where attackers can spoof the legitimate app's TLS fingerprint. Bot Shield was deployed there in observe-only mode to settle the question.

Why the WAF can't catch it: the abuse lives on the mobile-app API.

On the web, Turnstile gates the booking funnel and traffic looks clean. On the mobile-app channel there's no CAPTCHA to gate, so a real app customer simply walks through search → temporary booking → passenger details → payment. Distributed bots only ever start the second step on the same mobile-app endpoints, and never finish.

Animation 1

Booking funnel: real customer vs. distributed bot swarm

LIVE
STAGE 1
Search
GET /search
STAGE 2 · BOT TARGET
Temporary booking
POST /tempBooking · 8-min seat hold
STAGE 3
Passenger details
POST /passenger
STAGE 4
Payment confirmed
POST /pay → ✓
Real customer · 1 session every ~6 min
Searches, holds a seat, fills in passenger details, pays. Reaches stage 4.
✓
✓
✓
$
Distributed attackers · hundreds per hour
Each attempt arrives from a new IP, ASN, and User-Agent. Pulls GET /search, then POST /tempBooking, then abandons, never reaching passenger details or payment.
0
attempts · last hour
✓
✓
What the WAF sees: a perfectly valid mobile-app request: the right user-agent, the legitimate Android-app TLS fingerprint, a residential IP in a plausible country, and a clean POST /tempBooking call. No CAPTCHA was ever asked for; the mobile channel doesn't have one. What Bot Shield sees: the same session never returns, the same JA3 / JA4 fingerprint hits from forty other IPs in the next minute, and the funnel-conversion ratio for that fingerprint is exactly zero.

The cost shows up downstream: in held inventory and rising prices.

Each temporary booking puts a seat on hold for several minutes. Yield-management systems treat held seats as taken and quietly raise the published price. Real customers either pay the inflated fare or walk away.

Animation 2

One flight · seats & price as the swarm holds inventory

LIVE
FLIGHT XX-1408 · 60 SEATS
Lowest published fare
€129
▲ €0 (vs. baseline)
Inventory state
Available60
Booked (real)0
Held by bots0
Price over time
What you can see in this scene: real customers (green) trickle in slowly. Bots (pink) hold seats in bursts; each hold expires after the airline's grace window, but by then the published price has already crept up. The carrier sees rising prices and falling conversion; revenue management sees demand that doesn't actually exist.
The challenge

What Bot Shield surfaced on the mobile-app API.

  • Channel pivot: the web funnel was clean (WAF + Turnstile + Bot Management). The same actors moved to the mobile-app API where no CAPTCHA could be displayed.
  • Mobile-app TLS spoofing: the legitimate Android-app JA3 / JA4 fingerprints were being replayed from desktop tooling on off-network ASNs, so the requests looked like real app traffic.
  • Residential-proxy rotation: single attacker sessions appeared from dozens of consumer ASNs, defeating per-IP rate limits on the mobile endpoints.
  • Temporary-booking holding: bots called tempBooking on the mobile-app API and used the carrier's grace window to keep seats blocked without ever paying.
  • Country-level distortion: low-conversion geographies on the mobile channel skewed dashboards and routing decisions for revenue management.
The approach

How Bot Shield was deployed.

  • Mobile-app channel only: the web channel stayed on its existing Cloudflare stack. Bot Shield ran in front of the iOS / Android app's API endpoints, where Turnstile can't gate without breaking UX.
  • LOG-mode pilot: four weeks of observe-only scoring while signals were tuned against the carrier's real mobile-app traffic.
  • Custom signal library: fourteen detection signals defined per route (search, tempBooking, passenger, payment) instead of generic global rules.
  • JA3 / JA4 reputation: fingerprints scored against the legitimate iOS / Android app baseline, so spoofed app traffic from desktop ASNs got flagged immediately.
  • Channel-aware leniency: home-market frequent flyers on the real mobile app exempted from volume and no-payment signals to avoid false positives.
  • ENFORCE rollout: block thresholds raised gradually after stakeholder review of the LOG-mode evidence.
Findings from the LOG-mode pilot

What changed once Bot Shield was on.

Signals
14 detection signals tuned to the funnel.
Bot families
Identified via JA3 / JA4 fingerprint reputation.
False positives
Prevented on home-market mobile customers.
Infra cost
Stayed on the Cloudflare free tier through pilot.

Three radar views from the LOG-mode dashboard make the abuse pattern impossible to miss. The 1 h shape bulges past the 7 d baseline on the axes that matter: a brand-new fingerprint, a country never seen before, and a single attack signal pinned at the maximum.

Fingerprint profile
JA3 / JA4: new combinations
NEW
Red labels: JA3 / JA4 combinations seen in the last hour but absent from the past 7 days. Each one is a brand-new fingerprint hitting tempBooking.
Geographic profile
Countries: new & no-pay
NEW
VN tops the 1 h rank with traffic never seen in the previous 7 days; its 7 d shape is essentially zero. The other red countries pay below the 10 % conversion threshold.
Attack vectors
Signal cluster distribution
SURGE
geo_surge sits pinned at the maximum on the 1 h ring: almost every flagged session in the last hour fired this signal. The 7 d baseline for the same signal is a third of that.

How to read these: each axis is one fingerprint, country, or signal. The three filled polygons show how much of total flagged traffic that axis represents over 1 h, 24 h, and 7 d. When the 1 h shape bulges far past the 7 d shape on a red-labelled axis, you're watching the start of a new attack, usually minutes before yield management notices it in conversion.

Outcome

From observation to enforcement.

Pattern of abuse on the mobile-app channel documented end-to-end with per-session evidence (signals, fingerprints, ASN, country, request path) and exportable to CSV for the carrier's own analyst team. Bot Shield moved into ENFORCE on the mobile-app routes that matter most (temporary booking and payment confirmation), with a customer-set whitelist for trusted partners and aggregator IPs. The web channel kept its existing Cloudflare stack untouched. The dashboard now serves as a daily operational tool for the carrier's revenue-protection and security teams.

Ongoing engagement covered by a Brixio Support / Managed Services plan: quarterly reviews, signal updates, and app-release fingerprint whitelisting.

Sector perspective

AI-based bot scoring is now the baseline for high-yield travel APIs.

Airlines and online travel agencies face some of the most persistent and sophisticated bot activity of any industry. Temporary-booking abuse, credential stuffing on loyalty accounts, and fare-scraping are three distinct threat families that all share one property: they are operationally harmless on their own but together distort pricing, revenue management decisions, and conversion analytics. Bot Shield's LOG-mode-first deployment approach lets a carrier build an evidence base before any enforcement decision, and the JA3/JA4 mobile-fingerprint layer is what makes the airline channel actionable without a CAPTCHA.

IATA NDC PCI DSS (API layer)
AI Security & Bot ShieldTransport & Mobility industry
Protect your booking API

Seeing similar patterns on your mobile or API channel?

Bot Shield deploys in LOG mode first: no traffic impact, no CAPTCHA friction. Four weeks of evidence before any enforcement decision.

Talk to Bot Shield More case studies