I&#x27;m not sure if this had been mitigated in the standard, but the pinning implementations I&#x27;ve seen used in Android apps rely on client-side (i.e. app) verification. It&#x27;s an inconvenience, for sure, for someone trying to emulate the app (in order to connect to the server API). But it&#x27;s not sufficient to stop a determined attacker with a bytecode decompiler.<p>For instance: <a href="http:&#x2F;&#x2F;randywestergren.com&#x2F;reverse-engineering-the-subway-android-app&#x2F;" rel="nofollow">http:&#x2F;&#x2F;randywestergren.com&#x2F;reverse-engineering-the-subway-an...</a><p>EDIT: Just to clarify given the comment below (and downvotes...), I&#x27;m talking about a different attack scenario. Here&#x27;s a decent source on some of pinning&#x27;s weaknesses for your standard MITM scenario: <a href="https:&#x2F;&#x2F;www.owasp.org&#x2F;index.php&#x2F;Certificate_and_Public_Key_Pinning#Pinning_Gaps" rel="nofollow">https:&#x2F;&#x2F;www.owasp.org&#x2F;index.php&#x2F;Certificate_and_Public_Key_P...</a>