Using Approov with emulators
Approov MITM_DETECTED when testing in hosted emulators or device clouds
Summary
When running an Approov-protected mobile app in a hosted emulator, simulator, or device-cloud environment such as Appetize, BrowserStack, AWS Device Farm, Sauce Labs, or similar platforms, the app may fail to start or may remain on a splash/loading screen. Logs may show that every fetchApproovToken call returns:
MITM_DETECTED
This usually means that the testing platform, an enterprise proxy, or a network-inspection feature is intercepting HTTPS traffic between the app and the Approov cloud attestation service.
Approov is designed to detect this condition. The fix is to make sure Approov SDK traffic can reach the Approov cloud directly over HTTPS, without TLS/SSL inspection, certificate substitution, network-intercept mode, or a man-in-the-middle proxy. Approov’s CLI includes approov sdk -accessedURLs, which lists the URLs the SDK may access and notes that these domains must be reachable directly without TLS interception by a firewall.
Symptoms
You may see one or more of the following: The app hangs on the splash screen or login options never appear. Approov token fetches fail with:
MITM_DETECTED
The issue appears only in a hosted emulator/device-cloud environment, but not on a normal physical device or local development device.
The problem started after enabling network capture, HTTP archive collection, proxy routing, “intercept” mode, enterprise network monitoring, or a local-testing tunnel.
Why this happens
Approov token fetches require the Approov SDK in the app to communicate securely with the Approov cloud service. During this process, the SDK measures the app and runtime environment, and the Approov cloud decides whether to issue a valid short-lived Approov token. Approov documentation describes this SDK/cloud integrity-check flow and notes that the communication is protected by TLS and an additional request-integrity-signing layer.
Many hosted emulator and device-cloud platforms provide network debugging features. These features are useful for normal testing, but some of them work by intercepting HTTPS traffic and presenting their own certificate to the app. From Approov’s perspective, that is indistinguishable from a real man-in-the-middle attack.
When the Approov channel itself is intercepted, Approov correctly reports MITM_DETECTED. The Direct SDK documentation classifies MITM_DETECTED as a retry-type network condition and notes that a special message may be appropriate because the network may be intercepting TLS.
Important distinction: proxy vs TLS interception
Not every proxy is a problem. A plain forwarding proxy that uses HTTP CONNECT and leaves the HTTPS session end-to-end encrypted may work, provided the Approov hosts are reachable and the certificate chain is not modified. Appetize, for example, documents a proxy mode where HTTPS traffic remains encrypted and the proxy acts as a TCP forwarder. The problem is TLS/SSL interception, also described as HTTPS inspection, network intercept, MITM proxy, certificate substitution, or decrypting proxy. Approov traffic must bypass that kind of inspection.
Resolution
1. Disable HTTPS interception for Approov traffic
Configure the emulator, device cloud, enterprise proxy, local-testing tunnel, or network-monitoring tool so that Approov SDK traffic is not intercepted. Use:
approov sdk -accessedURLs
to get the current list of URLs that the SDK may access. Add those destinations to the relevant “do not inspect,” “bypass SSL inspection,” “allow direct,” or “no MITM” list in your testing platform or corporate proxy. The same Approov CLI reference notes that the command also provides an example curl command to verify access to the primary Approov servers. The required behavior is:
App in emulator/device cloud
-> direct HTTPS/TLS connection
-> Approov cloud
Not:
App in emulator/device cloud
-> intercepting proxy / TLS inspection / substitute certificate
-> Approov cloud
2. Check whether network capture or intercept mode is enabled
Look for settings with names such as:
Network Intercept
Network Traffic Monitor
HTTP(S) Capture
MITM proxy
SSL inspection
HTTPS inspection
Proxy capture
Force proxy
Force local
Local testing proxy
HAR capture
For Appetize, check whether the session URL or JavaScript SDK config sets the proxy to intercept. Appetize documents network capture using &proxy=intercept or proxy: "intercept" in the JavaScript SDK.
For BrowserStack, check BrowserStack Local and App Live/App Automate proxy settings. BrowserStack documents support for proxy, MITM proxy, and PAC-file configurations for Local Testing. BrowserStack also documents --force-proxy / --force-local behavior, where all requests can be routed through the configured proxy; avoid forcing Approov traffic through a MITM/decrypting proxy.
3. Do not “fix” this by trusting the proxy certificate for Approov
Some testing tools recommend adding the tool’s proxy certificate or certificate hash to an app when certificate pinning blocks network inspection. Appetize, for example, documents this as a possible resolution for general certificate-pinning issues during HTTPS traffic monitoring.
That is not the recommended fix for the Approov attestation channel.
Approov is intentionally detecting that the secure channel has been intercepted. The correct approach is to bypass TLS interception for Approov SDK traffic, not to weaken the Approov channel.
4. Confirm the app handles MITM_DETECTED gracefully
A MITM_DETECTED result should not leave the user stuck on a splash screen indefinitely. Approov’s Direct SDK guidance treats this as a retry condition where the API call should not proceed, and notes that a user-facing message may be appropriate because the network may be intercepting TLS. For example, instead of silently waiting forever, the app could show:
Secure connection unavailable.
This network or testing environment appears to be intercepting secure traffic.
Please disable HTTPS inspection for Approov traffic and try again.
Also check that synchronous token fetches are not being made directly on the main/UI thread. The Approov Direct SDK documentation notes that synchronous token fetching can block while network requests complete and must not be called directly from the main or UI thread.
Appetize-specific checklist
Check whether your Appetize URL contains:
proxy=intercept
or whether your Appetize JavaScript SDK configuration contains:
await client.setConfig({
proxy: "intercept"
})
If so, remove that setting for runs where Approov attestation must succeed, or configure the testing setup so that the Approov SDK URLs bypass interception. Appetize documents both per-app proxy configuration and network-intercept capture using the proxy setting.
If you still need to capture your own backend API calls, configure the capture tool to exclude Approov SDK destinations from TLS interception. Use approov sdk -accessedURLs to identify those destinations.
BrowserStack-specific checklist
Check whether BrowserStack Local is configured with:
MITM proxy
local proxy
force proxy
force local
PAC file
BrowserStack documents proxy and MITM proxy support for Local Testing, including options that route all traffic through the proxy.
For Approov-protected apps, configure the BrowserStack/local proxy setup so Approov SDK URLs are not routed through TLS interception. If traffic must go through a corporate proxy, the proxy should tunnel Approov HTTPS traffic without decrypting or replacing certificates.
This is separate from emulator/simulator rejection
MITM_DETECTED means the Approov channel appears to be intercepted. That is different from a policy decision to reject emulators or simulators.
After TLS interception is fixed, an emulator-based run may still fail with a different Approov result if the account policy rejects emulators/simulators. Approov’s policy documentation shows that the default policy rejects rooted/jailbroken devices, emulators, simulators, frameworks, and cloned multiapps, while other policies can be used for specific development or testing scenarios.
In other words:
MITM_DETECTED -> fix the network/proxy/TLS interception path
REJECTED -> check app registration, signing, device/emulator policy, and rejection reasons
What to send Approov Support
When opening a support case, include:
1. The testing provider: Appetize, BrowserStack, AWS Device Farm, Sauce Labs, etc.
2. Whether network capture, HAR capture, local testing, or proxy mode is enabled.
3. Whether the proxy performs TLS/SSL interception or only HTTP CONNECT forwarding.
4. The Approov SDK version and platform: Android or iOS.
5. The exact Approov fetch result: MITM_DETECTED, REJECTED, NO_NETWORK, etc.
6. Whether the same build works on a normal physical device.
7. The output of approov sdk -accessedURLs, if you are configuring allowlists.