Oh sorry, I probably should have been a little clearer. I&#x27;m thinking of a different attack scenario where the attacker wants to MITM your app to inspect traffic and utilise your server-side API for unintended purposes. So it looks like:<p>Attacker --&gt; Attacker&#x27;s Phone --&gt; App --&gt; MITM proxy --&gt; API&#x2F;Server<p>So you could use this to pull down real-estate listings from a real-estate app in an easily parsed format (usually JSON). Or write an app that pull down the odds from various sports betting app APIs, detects arbitrage opportunities and automatically places bets using their APIs...<p>EDIT: Oh and on the plaintext thing, generally no. Most apps will use TLS for app-to-server comms. Pinning in this context means they bundle the cert (or signature) with their app. By the looks of this (<a href="http:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;29988&#x2F;what-is-certificate-pinning" rel="nofollow">http:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;29988&#x2F;what-is-ce...</a>) it&#x27;s a similar story with chrome: they pre-bundle some signatures. The alternative is to pin on the first interaction, but this leaves you potentially vulnerable if an attacker is listening in on that first interaction. It also raises the question: what happens if the website needs to revoke and re-issue? Wouldn&#x27;t pre-bundling mean you&#x27;d have to wait for the next browser update (and for out of band commms to have occurred between google and the website)?