Yes. Certificate pinning raises the cost of intercepting an app's traffic, but an attacker who controls the device and the app copy can often change or remove it. Treat pinning as hardening, and design your API so that a hostile client still cannot do anything its user is not allowed to do.
What the guidance says
The OWASP Mobile Application Security Testing Guide is direct about this for Android. Certificate pinning is a hardening practice, but it is not foolproof, and it lists several ways an attacker can defeat it:
- modifying the certificate validation logic in the app's trust manager
- replacing pinned certificates stored in resource directories
- altering or removing pins in the network security configuration
Any such change breaks the app's signature, so the attacker has to repackage and re-sign the app. That is a speed bump for casual attackers and no obstacle for a motivated tester. The guide suggests integrity checks, runtime verification and obfuscation as additional layers, which again raise cost without making bypass impossible.
Who the attacker is
Think about whose device is being intercepted. In a normal pinning threat model, the user is the victim and the attacker sits on the network. Pinning helps there.
In a security testing or fraud model, the person holding the phone is the attacker. They own the device, can install their own certificate authority and can modify the app. Pinning no longer protects you from them, and the OWASP pinning cheat sheet makes a similar point: an attacker with the ability to update a trust store may be able to change how the app works, potentially defeating pinning.
What this means for API design
If the client can lie, the server must not trust it. Practical consequences:
| Do not rely on | Rely on |
|---|---|
| The app hiding endpoints or parameters | Authorization on every request, server side |
| The app limiting what a user can send | Input validation and size limits on the server |
| A hidden key in the app | Per user tokens with short lifetimes |
| Pinning to stop testers | Rate limits, logging and anomaly detection |
| The app enforcing business rules | Business rules enforced in the API |
OWASP's mobile guidance says to assume all client side controls can be bypassed and to perform them on the server as well.
What pinning still does well
Pinning is not useless. It protects ordinary users on hostile networks from attackers who obtain a rogue certificate, and it makes bulk passive interception harder. It also forces curious testers to put in effort. The point is to avoid overestimating it.
Should you test your own pinning?
Yes, in two ways. First, confirm that the app refuses a connection when the certificate does not match, using a test proxy. Second, run your API tests against the backend directly, as an attacker would, with a valid token and no app in the way. If the second set of tests finds anything, the problem was never the pinning.
A short checklist
- Write down what pinning protects against in your threat model.
- Add a backup pin and an update plan.
- Keep every authorization decision on the server.
- Assume your API will be called by tools, not just by your app.
- Log and alert on unusual use of valid credentials.
- Add app integrity signals where they make sense, as one signal among several.
Safeguard's SBOM and dependency scanning shows which libraries sit inside your mobile build, which is a useful baseline before you test it. A free scan is at gold.safeguard.sh/scan.
Quick check
If pinning can be bypassed, should we remove it?
Not necessarily. It still helps against network attackers. The mistake is treating it as a barrier against the device owner.
Does obfuscation stop a pinning bypass?
It makes the change harder to find. It does not prevent it, and OWASP lists it as an extra layer rather than a solution.
Sources
- OWASP MASTG, Certificate Pinning on Android
- OWASP Pinning Cheat Sheet
- OWASP Mobile Application Security Cheat Sheet
Last reviewed: 19 October 2026.
