SSL certificate pinning on Android is a valuable control that blocks casual traffic interception, but it can be bypassed on a device the attacker fully controls, which is why it should be one layer, not a guarantee. On a rooted device, a runtime instrumentation toolkit like Objection, built on Frida, can hook and disable an app's pinning check so traffic can be inspected. Understood defensively, this tells you two things: test your own app's pinning during authorized security assessments on an isolated device you own, and never assume pinning alone protects sensitive data, since a determined attacker on their own device can defeat it. Pair pinning with server-side validation.
Short answer
Certificate pinning resists casual interception but is bypassable on a controlled, rooted device, so treat it as defense-in-depth. Objection, an open-source toolkit built on Frida, is used in authorized security testing to hook an app's pinning verification and, per the Objection project, disable common pinning implementations at runtime on a device you own. This is possible because pinning is a client-side check, which a rooted device can instrument. Test only your own app, on an isolated rooted device, in line with OWASP MASTG network-testing guidance. The defensive takeaway is to pin correctly, but also validate on the server and never rely on pinning to protect secrets sent from the client.
What SSL pinning does and why it is bypassable
Certificate pinning makes your app trust only a specific server certificate or public key, rather than any certificate a system trust store would accept. This blocks a common interception method, where an attacker places a proxy with their own certificate between the app and the server, because the app rejects the proxy's certificate as unpinned. For casual man-in-the-middle attempts on a normal device, pinning works well.
It is bypassable because the pinning check runs inside your app, on the device. On a device the attacker fully controls, such as a rooted phone, they can observe and modify your app's behavior at runtime, including the code that performs the pinning check. So the same property that lets pinning protect a normal user, a check inside the app, is what lets it be defeated on a device where the attacker has full control, which is the core limitation to design around.
What is Objection?
Objection is an open-source runtime mobile exploration toolkit built on Frida, used by security testers to assess their own or authorized apps at runtime. It provides commands to inspect and interact with a running app, and among them is the ability to attempt to disable common SSL pinning implementations, which testers use to check whether an app's pinning holds and to inspect traffic during an authorized assessment. It is a legitimate security-testing tool, not malware.
Its role in pinning testing is to answer a specific question: does this app's pinning actually resist a runtime bypass? By hooking the pinning verification on a device the tester controls, Objection reveals whether the control can be turned off, which is exactly what a real attacker on a controlled device might attempt. Used against your own app, it tells you how much your pinning is really protecting, so you can strengthen it and design around its limits.
Testing your own app: rooted device setup
Responsible testing happens on a device or emulator you own, in an isolated environment, against your own app. The typical setup for authorized pinning testing uses a rooted device or an emulator with root, with the Frida server running on it and Objection installed on your machine to connect to the target app. To observe traffic, testers pair this with an intercepting proxy whose certificate authority is installed on the test device.
The important framing is scope and authorization. This setup is for evaluating software you own or are explicitly permitted to test, never for intercepting other people's apps or traffic. Keep the device isolated, use test accounts and test data, and treat the exercise as measuring your own control's resilience. The goal is to learn whether your pinning can be bypassed so you can harden it, in line with OWASP MASTG guidance on testing network communication for your own app.
Why client-side pinning can be defeated
Client-side pinning can be defeated because, on a controlled device, nothing the app does is truly hidden from the person who owns the device. Runtime instrumentation lets them replace the behavior of the pinning check, so a function that would reject an untrusted certificate can be made to accept it. No amount of cleverness in the check removes this, since the check still executes in an environment the attacker controls.
This is the same class of limitation as any client-side security control on a device the attacker owns. It does not make pinning useless; pinning still stops interception on normal, unmodified devices, which covers a large share of real threats. But it does mean pinning is not a barrier against a determined attacker on their own rooted device, and treating it as one, for example by assuming a secret is safe in transit because the app pins, is the mistake to avoid.
How to test pinning responsibly
Test only your own app, on an isolated device you control, with the goal of measuring and improving your pinning. Use the authorized setup to check whether a runtime bypass disables your pinning, whether your app detects or resists the tampering, and whether any sensitive action still succeeds once pinning is bypassed. Each finding points to a concrete improvement, such as adding server-side validation or removing a client-side assumption.
Keep the work scoped and remediation-focused. The point is not to produce a reusable bypass but to understand your control's resilience, so you can decide how much to rely on it and what to layer alongside it. Document what you find on your own app, fix the gaps, and re-test, which is how authorized security testing turns a bypass demonstration into a stronger app.
Hardening: pinning as defense-in-depth
Harden by treating pinning as one layer within a defense-in-depth design. Implement pinning correctly, so it blocks interception on normal devices, but do not depend on it as the only protection. Validate and authorize sensitive operations on your server, where the attacker has no control, so a bypassed client-side check does not by itself grant access or expose data. Keep secrets and trusted logic off the client, since pinning does not protect what an attacker can reach on their own device.
You can add tamper and root detection to raise the effort further, but recognize that those are also client-side controls a determined attacker can bypass, so they are speed bumps rather than walls. The durable protection comes from the server and from not placing more trust in the client than a controlled device can be given. Pinning belongs in that design as a valuable layer, not as the whole defense.
What pinning protects and what it does not
Being precise about pinning's coverage helps you rely on it correctly. The table below separates the threats it blocks from those it does not.
| Threat | Blocked by pinning? |
|---|---|
| Casual man-in-the-middle with a custom certificate | Yes |
| Interception proxy on public Wi-Fi, normal device | Yes |
| Rooted device with a runtime hook, such as Objection | No |
| A determined attacker on a device they fully control | No |
| A secret sent from the client, assuming pinning protects it | Not truly protected |
Read the table as pinning's boundary. It covers interception on normal devices well, and it does not cover an attacker who controls the device, which is why anything that must resist that attacker belongs on the server, not behind pinning alone.
Hardening checklist
A short checklist turns the limits into fixes. The list below covers the measures that matter.
| Check | Action | Done? |
|---|---|---|
| Implement pinning | Pin correctly as a layer against interception | [ ] |
| Do not rely on it alone | Validate and authorize sensitive actions server-side | [ ] |
| Keep secrets off the client | Do not trust the client with what it should not hold | [ ] |
| Test your own app | Run authorized pinning tests on an isolated device | [ ] |
| Plan for bypass | Assume a controlled device can defeat client-side controls | [ ] |
The two that matter most are server-side validation and keeping secrets off the client, since those hold even when pinning is bypassed. Pinning and any tamper detection add cost for an attacker, but the durable protection is on the server, which a rooted device cannot reach.
What to take away
- Certificate pinning blocks casual interception on normal devices, but it is bypassable on a rooted device the attacker controls, so it is one layer, not a guarantee.
- Objection, a Frida-based toolkit, is used in authorized testing to hook and disable an app's pinning, revealing how well the control holds.
- Pinning is defeated because it is a client-side check that a controlled device can instrument, the same limit as any on-device control.
- Test only your own app on an isolated device, and harden by validating server-side and keeping secrets off the client.
- Pin as defense-in-depth, and scan with PTKD.com to find where pinning or other network protections are missing.
