Should a React Native payments app pin certificates at all, and how would you decide?

## The decision interviewers want to see "Should we pin?" has no universal answer, which is why it is asked of leads. A strong answer weighs a specific threat against a specific operational cost and scopes the decision instead of choosing all or nothing. ## What pinning adds on top of HTTPS HTTPS with the platform's default trust already defeats an attacker who merely sits on the network: they cannot produce a valid certificate for your domain. Pinning helps in a narrower set of cases, where a certificate the device **accepts** is nonetheless not yours: - a certificate authority mis-issues or is compromised; - a CA was added to the device by the user, malware or a management profile, the scenario the React Native security guide describes; - traffic inspection by a network appliance whose CA the device trusts. How much of that remains depends on the platform. Apps targeting Android 7.0 and later do not trust user-installed CAs by default, which already removes the most common interception route on Android, while a device-management profile can still add trusted roots on managed devices. ## What pinning costs | Cost | Why it matters for a React Native app | |---|---| | Lock-out risk | a key change the installed pins do not cover breaks every such version, and native pins cannot be changed over the air | | Rotation discipline | backup keys, per-release pin records, a version-support window | | Debugging friction | QA proxies need debug-only trust; support cannot inspect production traffic | | Infrastructure coupling | a CDN, WAF or vendor front end that presents its own certificate must be included in the plan | | Third parties | pinning an SDK vendor's domain ties your uptime to their key schedule | ## A decision framework 1. **What travels over this connection?** Payment instructions and session tokens justify more than a public product catalogue. 2. **Who controls the endpoint and its keys?** Pin only domains whose key lifecycle your team controls. 3. **Can we run rotation?** If nobody owns backup keys and a version-support window, pinning will eventually cause an outage. 4. **Which platform gaps remain?** Take Android's default distrust of user CAs into account, and think about managed devices. 5. **What is the failure mode?** Prefer mechanisms that degrade safely: Android `pin-set` expiration, a minimum-version check, and pins on keys rather than certificates. ## Typical outcomes - **Payments or banking app, own API**: pin leaf or intermediate public keys with at least one backup; set an expiration on Android; keep the version-check path alive. - **Content app with no sensitive data**: no pinning; rely on HTTPS, ATS and Android's defaults. - **Enterprise app on managed devices where inspection is expected**: pinning may conflict with the organisation's own security tooling; agree the policy with them first. ## Writing the decision down Whatever the answer, record it so the next team does not relitigate it or forget its obligations: - the threat being addressed and the domains in scope; - which keys are pinned, where the backup keys are held, and who may use them; - the fail-open or recovery path per platform (Android expiration, minimum-version check); - a review trigger, such as a CA change, a new CDN in front of the API, or a change in platform defaults. ## What not to conclude - Pinning does not protect a device that is already compromised; a hooking framework can disable checks inside the app, which is why integrity checks are a separate layer. - Pinning is not a substitute for server-side controls; it narrows who can impersonate your server, not what an authenticated client may do.