Our mobile application began experiencing sporadic HTTP 403 errors from our API endpoints this morning, coinciding with our recent enablement of Cloudflare's updated Bot Fight Mode. The pattern suggests the service is incorrectly classifying legitimate, automated API calls from our compiled mobile application as bot traffic.
We have a standard REST API backend served through Cloudflare, with the mobile app using token-based authentication. The errors are not universal but appear to affect approximately 15-20% of POST/PUT requests, which is severely impacting user session stability. The request flow is typical:
```http
POST /api/v3/user/update_preferences HTTP/1.1
Authorization: Bearer
Content-Type: application/json
User-Agent: MyApp/2.1.4 (Android 13; SM-G998B)
{"preference": "theme_dark"}
```
From our latency profiling, we see the 403 responses are returned from Cloudflare's edge with minimal backend processing time, confirming the block is at the WAF/Bot Management layer. The challenge is that these are not browser-originating requests; they are direct API calls from a controlled, first-party client.
Key observations and configuration context:
* We are on a Cloudflare Pro plan with Bot Fight Mode set to "On."
* Our WAF custom rules are minimal and do not target our API paths.
* We do not use Cloudflare's mobile SDK, which may be a factor.
* The issue is intermittent, suggesting the heuristic scoring is flapping for some user sessions or request patterns.
The core tradeoff here is security versus availability for first-party clients. I am seeking to understand:
* The specific signals the new Bot Fight Mode uses to classify non-browser, programmatic clients.
* Whether there is a recommended method to whitelist our mobile app's traffic without disabling protection for other routes.
* If anyone has implemented a successful mitigation, perhaps via a Worker to validate the client before the Bot Fight Mode evaluates the request, or via careful use of the `CF-Connecting-IP` and allowlisting.
Our immediate workaround is to disable the feature, but that is not a sustainable security posture. A long-term solution requires a precise understanding of the mechanism to avoid simply poking holes in the defense.
brianh
Classic Cloudflare. Their bot detection's always been a blunt instrument, especially with mobile app traffic. You're on Pro, so you can at least see the Security Events log and add a rule.
Seen this exact pattern with a client's Salesforce Mobile SDK. The User-Agent string from compiled apps trips it. You'll probably need to create a Firewall rule to allow traffic from your app, maybe using the CF-Connecting-IP header or a specific ASN if your mobile backend is consistent.
Painful, but their 'managed' solutions always require you to manage the exceptions.
CRM is a means, not an end.
Ah, the classic "my legitimate client is a bot" scenario. The 15-20% sporadic rate on POST/PUT is the real tell - that's often the fingerprint of the "JavaScript Detected" subcategory within Bot Fight Mode flagging requests that don't exhibit typical browser behavior, which compiled mobile apps obviously don't.
Since you're on Pro, your immediate move should be the Security Events log, but I'd drill down specifically for the "Bot Fight Mode" managed source and look for the "JS Check" action. That's usually the culprit for native app traffic.
While a firewall rule to bypass is the quick fix, you might also want to check if your mobile framework is sending consistent HTTP header ordering or if there's something in the request timing pattern that's triggering it. I've seen cases where retry logic from a mobile library, under poor network conditions, accidentally mimics scraping behavior.
The real nuisance is that you'll need to maintain this allow rule not just for this version, but as you roll out new app versions, unless you can identify a more static signature to match, like a specific header your app injects. It's a band-aid, but it works.
Stay connected