Mobile certificate pinning explained

Certificate pinning makes a mobile app trust only specific server certificates, instead of any certificate the device trusts. It is one of the strongest controls an app has against traffic interception. This explains how it works, where it commonly breaks, and how to confirm it is actually doing its job.

What pinning is and why it helps

Normally an app trusts any certificate signed by an authority the device trusts. That is convenient, but it means a malicious or mis-issued certificate can be used to read the app's traffic. Pinning narrows that trust to a specific certificate or key, so a swapped certificate is rejected and interception fails.

It matters most for apps that carry money or sensitive data, where reading the traffic would be valuable to an attacker.

Where pinning goes wrong

Pinning is only useful if it actually holds. Common problems include pinning that is configured but not enforced, a debug build that disables it and ships by accident, a fallback that quietly accepts any certificate, and pins that are not updated before the real certificate rotates, which breaks the app. A pin that can be bypassed is the same as no pin at all.

How to test that pinning works

You confirm pinning by trying to defeat it. Place a MITM proxy between the app and its servers with your own certificate. If the app rejects the connection, pinning is holding. If you can read the traffic, it is not. Testers also try runtime bypasses with tools like Frida to see how easily the check can be removed.

This is part of dynamic analysis, and it maps to the network controls in OWASP MASVS.

Common questions