SSL pinning: what it is and does your app need it?

SSL pinning, more precisely certificate or public-key pinning, means a mobile app accepts only specific keys for its own servers, instead of any certificate from any trusted certificate authority. It exists because an app's traffic can be intercepted by anyone who gets an extra root certificate trusted on a phone, or who obtains a wrongly issued certificate. It is a useful layer for logins, payments and paid content, but it can be switched off on a compromised device, and careless pinning can lock users out when a certificate changes.

How attackers intercept an app's traffic

Ordinary TLS trusts any certificate that chains up to any root in the device's trust store. That is how the web works, as our guide to PKI and certificates explains. For an app that only ever talks to its own servers, it leaves three openings:

• An extra root on the device. Traffic-inspection tools work by getting their own root certificate trusted on a phone, then presenting certificates they create on the fly. Whoever controls the phone, including its owner, can set this up.
  
  
• A hostile network. On an untrusted Wi-Fi network, someone can try to sit between the app and the server. Normal certificate checks stop most of this, unless a trusted root or certificate has been compromised.
  
  
• A wrongly issued certificate. If any trusted certificate authority were tricked into issuing a certificate for your API's domain, ordinary TLS would accept it.
  
  

Why would anyone bother? For a paid-content app, the most curious person is often a user on their own phone, trying to see how the app talks to its servers: where lessons come from, what the login tokens look like, which requests could be replayed or automated. Others want to capture a shared account's session, or script the app to scrape content.

The platforms narrow part of this risk by default. Android apps that target Android 7.0 or later ignore user-added certificates unless the app opts in, although rooted phones can get around that. On iOS, a user can install a profile containing a root certificate and switch on full trust for it, after which it is trusted for TLS connections, apps included.

How attackers tamper with apps

Interception is one half of the problem. The other is changing the app itself. Because an app runs on a device the user controls, an attacker can:

• run it on a rooted or jailbroken phone, where the operating system's protections no longer apply;
  
  
• modify and repackage it, stripping out checks and distributing the altered copy;
  
  
• alter it while it runs, using instrumentation tools that change what the app's functions do, including security checks;
  
  
• run it in an emulator, where many copies can be automated at once.
  
  

This matters for pinning because pinning is itself a check that runs inside the app. On a device the attacker fully controls, a determined attacker can disable it along with any other client-side check.

What pinning does, and why teams use it

With pinning, the app carries a record of the keys it expects from its own servers and refuses any connection presenting a different key, even one signed by a trusted certificate authority. On an unmodified app, that defeats all three interception routes above: an extra root on the phone, a hostile network and a wrongly issued certificate.

Teams add it when the traffic is worth protecting: payment and login flows, APIs that grant access to paid content, and anything an attacker could learn from and then automate. It is different from mutual TLS, where the server checks the client; with pinning, the app checks the server more strictly.

Both Android and iOS support pinning natively, and both vendors attach warnings. Android's documentation stresses always having a backup key. Apple's guidance on identity pinning says to deploy it "with caution, and only if absolutely necessary", because an app will refuse to connect if the server's keys change unexpectedly.

Why hardening is needed as well

Since pinning can be switched off on a compromised device, it is only one layer. Apps that protect money or paid content usually add runtime application self-protection (RASP): checks inside the app that notice tampering, instrumentation and hostile environments while it runs, and respond by limiting what the app will do or reporting to the server. Our guide to root, jailbreak and emulator detection covers the environment side.

Hardening has limits too. Every client-side check runs on hardware the attacker controls, so the aim is to raise the cost of an attack, not to make one impossible. That is why the decisions that matter most, such as who may access which content, belong on the server, where short-lived login tokens also make a captured request worth little; see our comparison of JWTs and sessions.

The limits of pinning

Rotation can lock users out

The classic pinning failure looks like this, in an illustrative example. An app pins only its API server's key. The certificate renews automatically at 6 a.m. on a mock-test day with a new key, and every student on an older app version fails to connect. The only fix is an app update that many won't install before the test starts.

This risk is growing. Public certificate lifetimes are shrinking in stages, to at most 47 days from March 2029, so certificate changes that once happened yearly will happen every few weeks; our guide to how SSL/TLS works has the schedule. The more often the pinned item changes, the more fragile pinning becomes.

Browsers learned this the hard way. Websites could once pin keys through an HTTP header, HTTP Public Key Pinning. Chrome removed it in version 72, citing very low adoption and the risk of denial of service and hostile pinning, according to Chrome's removal notice.

Coverage gaps in Flutter, React Native and SDKs

Pinning protects only the connections made through the layer where it is set up. Cross-platform frameworks such as Flutter and React Native, and third-party SDKs for video playback, analytics or crash reporting, can make connections of their own, so an app can look pinned while some of its traffic isn't. React Native's security documentation also warns that when a pinned certificate changes, apps carrying the old one stop working until they are updated.

What pinning never covers

• A modified app on a rooted or jailbroken device.
  
  
• Bugs on the server, such as an API that returns data it shouldn't.
  
  
• Data once it has been decrypted on the device, including whatever is shown on screen.
  
  

What to ask a vendor about SSL pinning

If a platform or agency builds your institute's app, you don't need its code, but you should get clear answers to these questions:

• Which of the app's connections are protected by pinning, including those made by third-party SDKs?
  
  
• What happens to students on old app versions when a certificate changes?
  
  
• How quickly would you notice, and fix, a pinning failure on a test day?
  
  
• What happens when the app runs on a rooted or jailbroken phone, or in an emulator?
  
  
• Which decisions are enforced on the server, so that a tampered app can't bypass them?
  
  

Good answers are specific about coverage and recovery. "Pinning makes the app unhackable" is a warning sign.

Key takeaways

• Apps can be intercepted through extra root certificates, hostile networks and wrongly issued certificates.
  
  
• Pinning makes an app trust only specific keys for its own servers, which defeats those routes on an unmodified app.
  
  
• Pinning runs on the device, so on a rooted or jailbroken phone it can be disabled; RASP and server-side controls are needed as well.
  
  
• Its biggest cost is the risk of locking users out when certificates change, which grows as lifetimes shrink.
  
  
• Cross-platform frameworks and third-party SDKs can leave traffic unpinned without anyone noticing.
  
  

Frequently asked questions

What is SSL pinning in Android?

On Android, SSL pinning means an app accepts only specific public keys for its own servers instead of any certificate trusted by the phone. Android supports it natively and recommends always including a backup key. Since Android 7.0, apps already ignore user-added certificates by default, so pinning mainly adds protection against compromised or wrongly issued system-trusted certificates, and against rooted phones where the defaults can be bypassed.

What is SSL pinning in mobile app?

In a mobile app, SSL pinning is a check where the app compares the server's certificate or public key with values built into the app and refuses the connection if they don't match. It protects traffic such as logins, payments and paid content from interception. It can be disabled on a compromised device, and it needs careful planning so certificate changes don't lock users out.

What is SSL pinning in iOS?

On iOS, SSL pinning restricts which public keys an app accepts for its servers, and Apple supports it natively. It matters on iOS because users can install root certificates and switch on full trust for them, which ordinary TLS would then accept. Apple recommends pinning with caution, only where truly necessary, and with more than one key, because unexpected key changes make the app refuse to connect.