React Native Security Checklist for Fintech Apps

Key facts, with sources

• React Native 0.76, released October 23, 2024, enabled the New Architecture by default and shipped with over 1,070 commits from 156 contributors plus a roughly 15x faster Metro resolver. (React Native official blog)
• The State of React Native 2024 survey collected 3,501 responses, up from about 2,400 the previous year, covering more than 15 areas of the ecosystem. (State of React Native survey)
• About 20% of State of React Native 2024 respondents reported apps with more than 100,000 users, up from 14% the year before. (InfoQ)
• Shopify migrated all of its mobile apps to React Native over five years and reports sub-500ms (P75) screen loads and over 99.9% crash-free sessions in production. (Shopify Engineering)
• 88% of surveyed React Native developers feel the framework is progressing positively, while better debugging remains the top request, cited by 54% of respondents. (SSOJet (State of React Native 2024 highlights))

Threat model: assume the bundle is public

Start from one assumption: everything shipped in your app — the Hermes bytecode, string constants, API routes, feature flags — will be extracted and read. Hermes bytecode is compilation, not encryption; tooling to inspect it exists, and even without it, strings are visible. Obfuscation raises attacker effort modestly and is worth doing, but no client-side measure keeps a secret.

The practical consequences: no API keys, signing secrets, or privileged credentials in JavaScript, in config files bundled with the app, or in environment variables baked in at build time. Any third-party service key that must ship client-side should be scoped to the minimum privilege the vendor allows. And every authorization decision — what this user may see, move, or withdraw — happens on the server, because client-side checks in a fintech app are decoration, not security.

Secure storage: Keychain and Keystore, nothing less

In code audits of fintech apps, the single most common critical finding is tokens in AsyncStorage. AsyncStorage is a plain, unencrypted file store — anything in it is readable on a compromised device and shows up in some backup scenarios. Secrets belong in the platform's hardware-backed stores: iOS Keychain and Android Keystore, reached from React Native via react-native-keychain.

Configure it deliberately rather than accepting defaults: mark items as accessible only when the device is unlocked and never migrated to another device, and gate the most sensitive credentials behind biometrics so a stolen unlocked phone still cannot mint new sessions. Store refresh tokens this way, keep access tokens in memory only, and treat 'we encrypt it ourselves with a key stored in JS' as what it is — a locked box with the key taped to the lid.

import * as Keychain from 'react-native-keychain';

const SERVICE = 'com.yourapp.auth';

export async function storeRefreshToken(token: string) {
  await Keychain.setGenericPassword('auth', token, {
    service: SERVICE,
    accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
    accessControl: Keychain.ACCESS_CONTROL.BIOMETRY_CURRENT_SET,
  });
}

export async function readRefreshToken(): Promise<string | null> {
  const credentials = await Keychain.getGenericPassword({ service: SERVICE });
  return credentials ? credentials.password : null;
}

Network layer: pinning, and what pinning costs

TLS alone does not stop an attacker who installs their own root certificate on a device they control — standard practice for API reverse-engineering. Certificate pinning closes that gap by accepting only your known certificates or public keys, and for fintech I consider it table stakes on the endpoints that move money or expose account data.

Pinning has a real operational cost that teams discover the hard way: pin to leaf certificates carelessly and a routine certificate rotation bricks every installed app until users update. Pin to the public key or an intermediate you control, always ship backup pins, and build the rotation runbook before you need it. Alongside pinning: strip request and response logging from release builds, never log tokens or PII through crash reporters, and make sure your HTTP client does not silently trust user-installed proxies in production.

Platform hardening: the visible-device problems

Fintech threat models include shoulder surfing, stolen devices, and malware-adjacent apps, so harden the visible surface. On Android, set FLAG_SECURE on sensitive screens to block screenshots and screen recording. On iOS, overlay or blur the app-switcher snapshot so account balances do not sit in the task switcher. Add an inactivity lock that re-requires biometrics after a short background period.

Root and jailbreak detection deserves nuance: detection libraries are all bypassable by a determined attacker, so treat their signals as risk inputs — factors your backend weighs when deciding whether to allow high-value actions or require step-up verification — rather than as a hard client-side block that mostly annoys power users. Finally, confirm the React Native dev menu and any debugging tooling are verifiably absent from release builds; audit findings here are rarer now but catastrophic when present.

Auth and session design

The pattern I ship: short-lived access tokens held only in memory, a long-lived refresh token in biometric-gated Keychain storage, and rotation on every refresh so a stolen refresh token dies the moment the legitimate app uses it. Sessions bind to a device identifier the backend tracks, giving users a visible device list and a remote revoke — which also gives your support team a kill switch during an account-takeover incident.

Step-up authentication belongs in the design from day one: viewing a balance and initiating a transfer are different trust levels, and the transfer should demand fresh biometrics or a PIN even mid-session. Handle the cold paths deliberately too — logout must wipe Keychain entries, and biometric enrollment changes should invalidate biometric-gated credentials, which the BIOMETRY_CURRENT_SET access control enforces at the platform level.

Dependencies, OTA updates, and release hygiene

Your dependency tree is part of your attack surface. Lock every dependency, run automated vulnerability audits in CI, and be genuinely conservative about adding packages — every native module you adopt is code you now vouch for to your regulator. Review what analytics and crash SDKs collect by default; more than one fintech team has discovered session-replay tooling capturing sensitive screens.

Over-the-air JavaScript updates deserve special caution in fintech. The capability is powerful for hotfixes, but shipping logic changes to a financial app outside your documented release and review process can create compliance questions, and your OTA provider becomes part of your supply chain. If you use OTA, restrict it to genuine hotfixes, sign and verify updates, and record each one in your change-management trail. Before launch, commission an external penetration test against both app and API — internal checklists, including this one, are the floor rather than the ceiling.

When to hire senior help

Bring in senior React Native help when facing a New Architecture or major version migration, persistent performance regressions, or a first store launch, since these are the phases where inexperienced teams lose the most months. A short senior architecture audit early in the project is consistently cheaper than a rescue or rewrite later. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — React Native Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Staying multiple versions behind on React Native, then facing a compound upgrade to the New Architecture because popular libraries have dropped old-architecture support
• ✕Treating React Native as write-once-run-anywhere and only QA-testing on iOS, shipping Android builds with broken back-button handling, keyboard behavior, and gesture bugs
• ✕Pulling in unmaintained third-party native modules without checking TurboModule and Fabric compatibility, which later blocks the New Architecture migration
• ✕Launching without crash and performance monitoring wired in, so the team only discovers jank and crash clusters from one-star reviews instead of telemetry

Frequently asked questions

Sources

• React Native official blog
• State of React Native survey
• InfoQ
• Shopify Engineering
• SSOJet (State of React Native 2024 highlights)