Certificate pinning bypass, in a legitimate context, means disabling or hooking an app's pinning check on a device you control so you can inspect its network traffic and confirm the protection actually works. You do this only on your own app, on an isolated rooted emulator or test device, never on production or someone else's app. The most common tool is Objection, which runs on Frida and can disable common pinning implementations at runtime. Pinning stops network attackers, but not an attacker who fully controls the device.
Short answer
Testing a certificate pinning bypass means running your own app on a rooted emulator or test device, attaching an instrumentation tool like Frida through Objection, and disabling the pinning check so a proxy can read the TLS traffic. The purpose is defensive: to verify your pinning works and to understand its limits. Per the OWASP Mobile Application Security Verification Standard, pinning belongs to secure network communication, not to secret storage. It raises the bar against man-in-the-middle attacks but can be bypassed by anyone who controls the device, so never rely on it alone. Keep all testing inside an environment you own and are authorized to test.
What is certificate pinning, and why test the bypass?
Certificate pinning is a client-side control where your app checks the server's certificate or public key against a copy it already trusts, and refuses the connection if they do not match. It defends against a man-in-the-middle attacker who presents a certificate from a rogue or mis-issued certificate authority, because a valid-looking CA certificate still will not match your pin.
You test the bypass to answer a defensive question: does my pinning actually hold, and what can an attacker see if it does not? A tester who can strip the pin on a controlled device learns exactly what data would leak if the control failed. That tells you whether pinning is configured correctly and, just as important, whether you are wrongly relying on it to protect data that needs server-side controls instead.
Test environment requirements
Do this work only on an app you own or are explicitly authorized to test, on a device or emulator you fully control. A rooted Android emulator image, isolated from real user data and production systems, is the standard setup. You attach a proxy such as mitmproxy or Burp Suite, install its CA in the test environment, and route the app's traffic through it.
The reason the environment matters is both legal and technical. Bypassing pinning on an app you do not own, or on someone else's device, is not authorized testing. And on a device you do not control, the bypass will not work anyway, because it depends on root or on repackaging the app. That is the whole point: the technique needs the kind of device control a normal remote attacker does not have.
How to use Objection to test pinning
Objection is a runtime mobile exploration toolkit built on Frida. On a rooted test device or emulator running the Frida server, you start a session against your own app with objection -g <your.package.name> explore, then run android sslpinning disable. Objection hooks the common pinning entry points at runtime, so the app stops rejecting your proxy's certificate and you can read the traffic.
If you cannot root the device, the usual alternative is to repackage your own debug build with the Frida gadget embedded, then run the same commands. Either way, this only works because you control the build or the device. Objection covers many standard implementations, but a custom or native pinning check may need a tailored Frida script, which itself tells you your implementation is less trivial to defeat.
OkHttp vs TrustKit: how pinning is implemented
OkHttp ships a built-in CertificatePinner that pins by public key hash. You add the SHA-256 hash of the server's Subject Public Key Info, and OkHttp rejects any connection whose certificate chain does not include a matching key. It is simple, code-based, and a good fit for apps that already use OkHttp for networking, as described in the OkHttp HTTPS documentation.
TrustKit is a dedicated pinning library, available for both Android and iOS, that adds configuration-driven pinning, backup pins, an enforcement toggle, and pin-failure reporting, per the TrustKit-Android project. Choose OkHttp's CertificatePinner when you want a minimal, in-code pin and already use OkHttp; choose TrustKit when you want centralized configuration, reporting, and a consistent approach across platforms. Both pin correctly when configured with public keys and backup pins.
Why pinning can be bypassed
Pinning is enforced by code that runs on the user's device, so anyone who controls that device can change what the code does. On a rooted device, a tool like Frida can hook the check and force it to pass. A repackaged app can have the pin logic patched out before install. Neither attack works remotely over the network, which is why pinning still defends against classic man-in-the-middle attacks.
The table below shows where pinning holds and where it does not, so you set expectations correctly.
| Attack vector | Pinning outcome | Takeaway |
|---|---|---|
| Rogue CA or MITM on the network | Blocked | Pinning does its core job |
| Mis-issued or compromised public CA | Blocked | The pin is independent of the CA system |
| Rooted test device with Frida hooks | Bypassed | Runtime hooking removes the check |
| Repackaged app with pin logic patched | Bypassed | Client-side code can be modified |
| Secrets assumed safe "because we pin" | Not protected | Pinning is not storage security |
The honest summary is that pinning raises the cost of a network attack but is not a secret. Treat it as one layer, effective against remote interception, not as protection for anything embedded in the app itself.
How to make pinning harder to bypass
You cannot make client-side pinning unbypassable, but you can make it correct and resilient, and avoid leaning on it for the wrong job. Pin to the public key, the SPKI hash, rather than a specific leaf certificate, so routine certificate renewals with the same key do not break your app. Always include a backup pin, so a planned key rotation does not brick every installed copy.
Beyond configuration, apply defense in depth. Add pin-failure reporting so you learn when pins fail in the field. Combine pinning with root and tamper detection, while remembering those are also bypassable and are signals, not guarantees. Most important, never store secrets client-side on the assumption that pinning protects them, and always enforce authorization on the server, so a bypassed client still cannot reach data it should not.
Hardening checklist
Use the checklist below when you review a pinning implementation. Each step maps to an OWASP Mobile Application Security Verification Standard category.
| Hardening step | Why it matters | OWASP area |
|---|---|---|
| Pin the public key (SPKI), not the leaf cert | Survives certificate renewal with the same key | MASVS-NETWORK |
| Include at least one backup pin | Avoids bricking the app on key rotation | MASVS-NETWORK |
| Enforce pinning and add failure reporting | Detects pin failures in the field | MASVS-NETWORK |
| Never store secrets client-side | Pinning does not hide embedded keys | MASVS-STORAGE |
| Authorize every request on the server | A bypassed client must still be stopped | MASVS-AUTH |
Run through these before a release, not after an incident. Most pinning problems in production are not exotic bypasses; they are a missing backup pin that bricks the app on renewal, or a team assuming pinning protects an embedded key that a quick bypass can read.
Where pinning fits in OWASP MASVS
In the OWASP MASVS, certificate pinning sits under secure network communication, and the OWASP MASTG documents how to test custom certificate stores and pinning on both Android and iOS. Using these as your reference keeps your testing aligned with a recognized standard rather than ad hoc checks.
The standards also reinforce the layering point. MASVS separates network security from storage, authentication, and platform interaction for a reason: each needs its own control. Pinning satisfies the network requirement, but a passing pin says nothing about whether your storage or authorization controls hold, which is exactly the trap a bypass test exposes.
Scan the build before you ship
Manual pinning tests are valuable, but they are one check among many, and it is easy to ship a build with a weaker issue elsewhere, such as an embedded API key, a debuggable flag left on, or cleartext traffic allowed for a subdomain. Those are the findings that make a pinning bypass almost beside the point, because the data was reachable another way.
A scanner like PTKD.com analyzes your .ipa or .apk and returns findings ordered by severity and mapped to OWASP MASVS, including network configuration, storage, and secrets, so you catch the weak spots before release. To be clear about its limits: an automated scan does not replace the hands-on pinning test described here, and it will not judge business logic or run a full manual audit for a high-risk app. Use it to clear the predictable issues, then spend your manual testing time on the ones that need judgment.
What to take away
- Certificate pinning bypass testing is a defensive exercise done only on your own app, on an isolated device you control.
- Objection on Frida can disable common pinning at runtime, which works precisely because it requires device control a remote attacker lacks.
- OkHttp's CertificatePinner suits in-code pinning; TrustKit adds configuration, backup pins, and reporting across platforms.
- Pinning defends against network attackers, not against a rooted device, so never store secrets client-side or skip server-side authorization.
- Scan every build with PTKD.com to catch network, storage, and secret issues that a pinning test alone will not.
