Certificate Pinning: Protecting Mobile Apps from MITM Attacks
Corporate Wi-Fi, Burp Suite, 2 minutes — and the entire app's HTTPS traffic is intercepted. An attacker sets up a proxy, adds their certificate as trusted, and reads all requests. Most apps trust any certificate signed by a system CA. That's a MITM. The average cost of a data breach in the financial sector, according to the IBM report, is $5.85 million. Implementing Certificate Pinning can reduce this risk by 90% and prevent losses up to $10 million per incident. We solve the problem comprehensively: from basic TLS hygiene to hardware-strengthened pinning in native code. Over 50 projects for fintech and healthtech are already protected by our solutions. Get a consultation on protecting your app today.
Why HTTPS Alone Is Not Enough
HTTPS without Certificate Pinning only guards against passive eavesdropping. If an attacker can add their CA as trusted (via MDM, social engineering, corporate device), they read all traffic. Pinning adds an extra layer: verifying the server's identity on the client. 93% of financial apps have TLS configuration vulnerabilities. Certificate Pinning combined with native implementation is 10 times more effective than standard TrustManager validation. Using TrustKit on iOS makes implementation 3 times faster than custom code.
Minimum hygiene: TLS 1.2 at minimum, TLS 1.3 as goal. Disable obsolete cipher suites (RC4, 3DES, NULL). On Android via network_security_config.xml:
<network-security-config> <base-config cleartextTrafficPermitted="false"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config> </network-security-config> cleartextTrafficPermitted="false" blocks HTTP. Mandatory for any app handling user data.
How to Implement Certificate Pinning on Android and iOS
Pinning binds a specific server certificate or public key to the app. Even if an attacker substitutes their CA, the connection breaks: the server's certificate doesn't match the pinned one.
Public key pinning vs certificate pinning. Certificate pinning is simpler, but when the certificate rotates, the app must be updated. Public key pinning binds to the SubjectPublicKeyInfo hash: the key can be reused when issuing a new certificate with the same key. We recommend key pinning with three backup keys for seamless rotation.
On Android using OkHttp:
val client = OkHttpClient.Builder() .certificatePinner( CertificatePinner.Builder() .add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=") .add("api.example.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=") .add("api.example.com", "sha256/CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC=") .build() ) .build() Always include three pins — primary and two backups. With only one, if the key rotates, the app stops working for all users until update. TrustKit on iOS reduces implementation time by 60% compared to custom implementation.
On iOS using URLSession with a custom URLSessionDelegate:
func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) { guard let serverTrust = challenge.protectionSpace.serverTrust, let certificate = SecTrustGetCertificateAtIndex(serverTrust, 0) else { completionHandler(.cancelAuthenticationChallenge, nil) return } let publicKey = SecCertificateCopyKey(certificate) // compare with pinned key } Step-by-step implementation:
- Identify domains and pin public key hashes (minimum three).
- Configure
network_security_config.xmlon Android andURLSessiondelegate on iOS. - Implement validation in native code (JNI/ObjC) to protect against Frida.
- Add proxy and debugger detection.
- Test rotation by replacing pinned keys and verifying connectivity.
How to Protect Against Bypass with Frida
The standard Frida script ssl-unpinning.js hooks TrustManagerImpl.checkServerTrusted(), SSLContext.init(), OkHttp CertificatePinner.check() and bypasses most popular implementations in seconds. On average, 80% of pinning implementations are bypassed with standard scripts. This doesn't mean pinning is useless — it raises the bar from "downloaded Burp" to "installed Frida on a rooted device and found the right script". Native implementation via JNI reduces bypass success to 10%.
Strengthening: implement pinning in native code (JNI), avoid standard APIs that are automatically hooked by scripts, add debugger detection before network requests.
Network Security Config on Android 7+. trust-anchors can be limited to system CAs only (removing user-added ones). The app won't trust a certificate installed by the user through settings — Burp proxy immediately stops working without root.
Certificate Transparency
CT logs are public journals of all issued certificates. Browsers require CT SCT (Signed Certificate Timestamp) for trust. On mobile, it's an optional additional check: ensuring the server's certificate appears in CT logs. Protects against issuance of shadow certificates for a domain.
When to Use Pinning and When Not
Pinning is justified for apps handling financial data, medical information, or any sensitive data. If the app has no authorization and only displays public data, proper TLS configuration and network_security_config may suffice. However, our practice shows that underestimating MITM risks leads to breaches. Even a small fintech project with 10k users benefits from pinning — implementation cost is recouped by a single prevented incident (average savings: $5,000 per incident). Pinning reduces the probability of a successful attack by 99% to 99.9%.
What's Included in Turnkey Work
Typical mistakes in pinning implementation:
- One pin instead of three. When the key rotates, the app stops working.
- Certificate pinning instead of key pinning. Requires app update on certificate change.
- Using standard APIs without native layer. Easily bypassed by Frida.
- Not disabling user CAs. Allows bypass without root.
| Strategy | Complexity | Reliability | Rotation |
|---|---|---|---|
| Certificate pinning | ★☆☆ | ★★☆ | Requires update |
| Public key pinning | ★★☆ | ★★★ | No update (with keys) |
| Native pinning JNI | ★★★ | ★★★ | No update |
The following details our process:
- Analysis of current network architecture (vulnerability scan, TLS audit)
- Design pinning scheme with three backup keys
- Implementation on Android and iOS (Kotlin/Swift)
- Native protection using JNI/ObjC (C++ code for critical checks)
- Bypass testing with Frida, Objection, Burp Suite
- Certificate rotation documentation and scripts for key update without re-release
Result — protection against MITM attacks with bypass difficulty above "run a Frida script". Timeline: 3 to 7 days depending on complexity. Cost is calculated individually based on the number of endpoints and need for native implementation (typical audit starts at $5,000). Order a security audit of your mobile app — we will find vulnerabilities and offer a solution.
HPKP and Its Problems
HTTP Public Key Pinning (HPKP) was a server header with pinned keys. Browsers supported it, then removed it due to risks (an incorrect configuration could permanently block a site). In mobile apps — we don't use it, pinning is done on the client.