n users' private photos — including photos they had uploaded but never posted. The vulnerability was an insufficient authorization check: third-party apps that were granted permission to view a user's timeline photos could also access their unpublished, Marketplace, and Stories photos. The API simply didn't enforce granular access control on the resource. In a fintech context, this is the equivalent of a payment confirmation endpoint that doesn't re-verify whether the authenticated user is the account owner — one missing authorization check and any authenticated user can access any account.

The fix: biometric gates on sensitive screens, not just login.

// src/security/biometric-auth.ts

import * as LocalAuthentication from "expo-local-authentication";
import { Platform } from "react-native";

export async function authenticateWithBiometrics(options: {
  reason: string;
  allowDeviceFallback?: boolean;
}): Promise<BiometricAuthResult> {
  const capability = await checkBiometricCapability();

  if (!capability.isAvailable || !capability.isEnrolled) {
    return {
      success: false,
      error:
        Platform.OS === "ios"
          ? "Please set up Face ID or Touch ID in Settings."
          : "Please set up fingerprint in Settings.",
      userCancelled: false,
    };
  }

  const result = await LocalAuthentication.authenticateAsync({
    promptMessage: options.reason,
    disableDeviceFallback: !options.allowDeviceFallback,
    fallbackLabel: options.allowDeviceFallback ? "Use Passcode" : "",
  });

  if (result.success) {
    return { success: true, userCancelled: false };
  }

  const userCancelled =
    result.error === "user_cancel" || result.error === "system_cancel";

  return {
    success: false,
    error: getBiometricErrorMessage(result.error),
    userCancelled,
  };
}

Enter fullscreen mode Exit fullscreen mode

The BiometricGateScreen wraps any sensitive screen. The child component doesn't even mount until auth succeeds — preventing any mount-time data fetching:

// src/screens/BiometricGateScreen.tsx

export function BiometricGateScreen({
  children,
  reason = "Authenticate to continue",
  allowFallback = false,
  onAuthFailure,
}: BiometricGateScreenProps) {
  const { capability, isEnrolled, authenticate, isLoading } = useBiometrics();
  const [isAuthenticated, setIsAuthenticated] = useState(false);
  const [attempts, setAttempts] = useState(0);
  const MAX_ATTEMPTS = 3;

  useEffect(() => {
    if (!isLoading && capability?.isAvailable && isEnrolled) {
      handleAuthenticate();
    }
  }, [isLoading]);

  const handleAuthenticate = async () => {
    if (attempts >= MAX_ATTEMPTS) {
      onAuthFailure?.();
      return;
    }

    const result = await authenticate(reason, {
      allowDeviceFallback: allowFallback,
    });
    if (result.success) {
      setIsAuthenticated(true);
    } else if (!result.userCancelled) {
      setAttempts((prev) => prev + 1);
    }
  };

  if (isAuthenticated) {
    return <>{children}</>;
  }

  // ... render authentication prompt UI
}

Enter fullscreen mode Exit fullscreen mode

Simulator gotcha: LocalAuthentication.authenticateAsync() always succeeds on iOS Simulator when Face ID is "enrolled" (Features > Face ID > Enrolled). On Android emulators, behavior varies by version. Always test biometric flows on a real device before your security audit. I've seen teams ship with biometric "protection" that they only ever tested on simulators.

Physical spoofing risk: Face ID has been bypassed with 3D-printed masks and fingerprint sensors with lifted prints. For high-value transactions (payments, withdrawals), always combine biometrics with a secondary factor — device passcode fallback at minimum, or a server-validated OTP for transactions above a threshold. Biometrics alone is a convenience feature, not a security guarantee.

In the Demo App

The Biometric Auth screen shows your device's capability (hardware, enrollment, security level, supported types), then lets you trigger two auth flows: a login prompt with passcode fallback, and a strict payment prompt with biometric-only (no fallback). The result box turns green on success, red on failure.

Checklist

• [ ] Biometric auth gates on payment, balance view, and settings screens — not just login
• [ ] Maximum attempt limit with lockout after failures
• [ ] Tested on real devices, not just simulators
• [ ] Fallback strategy defined (device passcode for low-risk, no fallback for payments)

---

M4: Insufficient Input/Output Validation

SQL injection in local SQLite: Yes, it happens in mobile apps. If you build SQLite queries with string concatenation, you're vulnerable.

Real-World Context: Input validation failures aren't just about SQL injection. WhatsApp's buffer overflow vulnerability (CVE-2019-3568) allowed attackers to install spyware with a single VoIP call — the target didn't even need to answer. The root cause was insufficient validation of incoming data in the call signaling protocol. In a React Native fintech context, your deep link handler and payment input fields are the most exposed surfaces — they accept data from outside your trust boundary (other apps, URLs, clipboard) and feed it directly into your business logic.

// ❌ WRONG — SQL injection in local database
const query = `SELECT * FROM transactions WHERE account_id = '${accountId}'`;
db.execAsync(query);

// ✅ RIGHT — Parameterized query
const result = db.getAllAsync(
  "SELECT * FROM transactions WHERE account_id = ?",
  [accountId],
);

Enter fullscreen mode Exit fullscreen mode

Deep link hijacking: React Native apps register URL schemes (yourfintech://) that can be invoked by any app on the device. If you don't validate deep link parameters, an attacker can craft a link that redirects to a phishing page or triggers unintended actions.

// src/security/certificate-check.ts

export function validateDeepLink(url: string): {
  valid: boolean;
  sanitizedUrl?: string;
  reason?: string;
} {
  try {
    const parsed = new URL(url);

    // Only allow your app's registered schemes
    const allowedSchemes = ["yourfintech", "https"];
    if (!allowedSchemes.includes(parsed.protocol.replace(":", ""))) {
      return { valid: false, reason: `Disallowed scheme: ${parsed.protocol}` };
    }

    // For https links, only allow your domains
    if (parsed.protocol === "https:") {
      const allowedHosts = ["yourfintech.com", "app.yourfintech.com"];
      if (!allowedHosts.includes(parsed.hostname)) {
        return { valid: false, reason: `Disallowed host: ${parsed.hostname}` };
      }
    }

    // Reject script injection in parameters
    for (const [key, value] of parsed.searchParams) {
      if (/<script/i.test(value) || /javascript:/i.test(value)) {
        return { valid: false, reason: `Suspicious parameter in ${key}` };
      }
    }

    return { valid: true, sanitizedUrl: parsed.toString() };
  } catch {
    return { valid: false, reason: "Malformed URL" };
  }
}

Enter fullscreen mode Exit fullscreen mode

Amount validation for payments — this is fintech-specific and gets missed:

// src/screens/SecurePaymentScreen.tsx

const validateAmount = (value: string): string | null => {
  const num = parseFloat(value);
  if (isNaN(num)) return "Please enter a valid amount.";
  if (num <= 0) return "Amount must be positive.";
  if (num > 50000) return "Amount exceeds single transaction limit.";
  // Precision attack prevention (e.g., 0.001 to drain funds via rounding)
  if (value.includes(".") && value.split(".")[1].length > 2) {
    return "Amount cannot have more than 2 decimal places.";
  }
  return null;
};

Enter fullscreen mode Exit fullscreen mode

In the Demo App

The Deep Link Validation screen has a live URL input — type or paste any URL and it validates in real time. The input border turns green for allowed URLs and red for blocked ones. Tap any of the preset buttons (phishing domain, XSS payload, JS injection, wrong scheme) to see them rejected instantly with a reason.

Checklist

• [ ] All SQLite queries use parameterized statements, never string concatenation
• [ ] Deep links validated against an allowlist of schemes and hosts
• [ ] Payment amounts validated for range, precision, and format
• [ ] TextInput fields use textContentType="none" and autoComplete="off" for sensitive data

---

M5: Insecure Communication

SSL pinning is mandatory for fintech. Without it, anyone on the same WiFi with a proxy (Charles, mitmproxy) and a self-signed CA installed on the device can read all your API traffic — including auth tokens, account numbers, and transaction data.

Real-World Incident: The British Airways breach in 2018 is the definitive example of what happens without communication security. Attackers injected a malicious script (just 22 lines of JavaScript) into the BA website and mobile app that skimmed payment card data — names, card numbers, CVVs, and expiry dates — as customers typed them. The data was exfiltrated to a look-alike domain (baways.com) in real time. 500,000 customers were affected and BA was fined £20 million by the ICO. The attack worked because there was no integrity check on the scripts being loaded and no pinning to verify the communication channel. In a React Native app without SSL pinning, an attacker on the same WiFi running mitmproxy achieves the same result — intercepting every API call, including payment data, in plaintext.

Hash pinning vs. certificate pinning: Use hash pinning. When you pin a certificate, you pin the entire cert — including its expiry date. When it rotates (every 90 days with Let's Encrypt), your pins break. Hash pinning pins the public key's SPKI hash, which survives cert renewals if the same key pair is reused.

How to extract your pin hash:

openssl s_client -connect api.yourfintech.com:443 \
  -servername api.yourfintech.com < /dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | base64

Enter fullscreen mode Exit fullscreen mode

// src/security/ssl-pinning.ts

import {
  initializeSslPinning,
  isSslPinningAvailable,
} from "react-native-ssl-public-key-pinning";

// Initialize once at app startup — after this, all fetch() calls
// are automatically pinned for the configured domains.
const PINNING_CONFIG = {
  "api.yourfintech.com": {
    includeSubdomains: true,
    publicKeyHashes: [
      // Primary: current certificate's public key hash
      "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=",
      // Backup: pre-generated backup key pair (CRITICAL — iOS requires 2+)
      "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=",
      // Disaster recovery: CA intermediate key hash
      "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC=",
    ],
    // Safety valve: after this date, pinning degrades to normal TLS
    expirationDate: "2026-12-31",
  },
};

// Call this in your app's entry point
if (isSslPinningAvailable()) {
  initializeSslPinning(PINNING_CONFIG);
}
// After initialization, standard fetch() is automatically pinned.

Enter fullscreen mode Exit fullscreen mode

The #1 production gotcha — cert rotation: If you only pin one hash and your certificate rotates with a new key pair, every user is locked out until they update through the App Store. This is not a hypothetical — I've seen it happen. Mitigations:

1. Always pin at least 2 hashes (current + backup key pair)
2. Set expirationDate — after this date, pinning disables gracefully
3. Monitor cert expiry server-side and push updated pins via OTA (expo-updates)
4. Have a kill switch — a remote config flag to disable pinning in emergencies

The secure API client wraps all of this into a clean interface:

// src/api/secureClient.ts

export function createSecureClient(config: SecureClientConfig) {
  // After initializeSslPinning(), the standard fetch() is automatically pinned.
  // No special fetch import needed — just use global fetch.

  async function request<T>(
    method: string,
    path: string,
    options?: RequestOptions,
  ) {
    const headers: Record<string, string> = {
      "Content-Type": "application/json",
    };

    // Inject auth token from SecureStore (not Redux, not AsyncStorage)
    if (!options?.skipAuth) {
      const token = await CredentialStore.getToken(
        CREDENTIAL_KEYS.ACCESS_TOKEN,
      );
      if (token) headers["Authorization"] = `Bearer ${token}`;
    }

    // Anti-replay: nonce + timestamp
    const nonce = await generateSecureHex(16);
    headers["X-Request-Nonce"] = nonce;
    headers["X-Request-Timestamp"] = Date.now().toString();

    // Request signing for tamper detection
    if (config.requestSigningKey) {
      const payload = `${method}:${path}:${headers["X-Request-Timestamp"]}:${nonce}`;
      headers["X-Request-Signature"] = await hmacSha256(
        payload,
        config.requestSigningKey,
      );
    }

    try {
      const response = await fetch(url, { method, headers, body });
      return response;
    } catch (error) {
      if (error instanceof SSLPinningError) {
        // Potential MITM — log to security monitoring
        throw createApiError("Secure connection failed.", { code: "SSL_PIN" });
      }
      throw error;
    }
  }
}

Enter fullscreen mode Exit fullscreen mode

In the Demo App

The SSL Pinning screen makes real HTTPS requests to demonstrate the concept. First, a normal fetch to jsonplaceholder.typicode.com succeeds — proving the network works. Then, the same request with a deliberately wrong pin hash gets BLOCKED before any data is sent. An ASCII diagram shows how a proxy attack works with and without pinning.

Checklist

• [ ] SSL public key pinning enabled for all API endpoints
• [ ] Minimum 2 pin hashes configured (current + backup)
• [ ] expirationDate set as a safety valve
• [ ] Cert rotation plan documented and tested
• [ ] Pin validation tested on a real device through a proxy (should fail)

---

M6: Inadequate Privacy Controls

What data you're accidentally logging: Flipper (the React Native debugger) logs every network request by default — including auth headers, request bodies with PII, and response bodies with account data. Sentry and Crashlytics capture breadcrumbs that often include screen names ("PaymentScreen"), user actions ("entered amount: 5000"), and even full stack traces with variable values.

Real-World Incident: In 2018, the MyFitnessPal breach exposed 150 million accounts — Under Armour disclosed that usernames, email addresses, and hashed passwords were stolen. Forensic analysis revealed that sensitive data was accessible in plaintext in the app's cache directory at /data/data/com.myfitnesspal/cache/ — extractable with one adb shell command on a rooted device. The data wasn't just in the database — it was in log files and cached API responses that nobody thought to encrypt. Your Sentry breadcrumbs and Flipper network logs are the React Native equivalent: unencrypted records of everything your user does, stored on disk.

// src/api/secureClient.ts

const SENSITIVE_FIELDS = [
  "token",
  "accessToken",
  "refreshToken",
  "password",
  "pin",
  "ssn",
  "accountNumber",
  "routingNumber",
  "cardNumber",
  "cvv",
];

export function maskSensitiveData(
  data: Record<string, any>,
): Record<string, any> {
  const masked = { ...data };
  for (const key of Object.keys(masked)) {
    if (
      SENSITIVE_FIELDS.some((f) => key.toLowerCase().includes(f.toLowerCase()))
    ) {
      const value = masked[key];
      masked[key] =
        typeof value === "string" && value.length > 4
          ? `***${value.slice(-4)}`
          : "***";
    } else if (typeof masked[key] === "object" && masked[key] !== null) {
      masked[key] = maskSensitiveData(masked[key]);
    }
  }
  return masked;
}

export function secureLog(label: string, data?: any): void {
  if (!__DEV__) return; // No logging in production
  if (data && typeof data === "object") {
    console.log(`[SECURE] ${label}`, maskSensitiveData(data));
  }
}

Enter fullscreen mode Exit fullscreen mode

Screenshot & screen recording prevention (iOS + Android): expo-screen-capture handles both platforms with a single API. On Android, it sets FLAG_SECURE (blocks screenshots, recordings, AND blanks the app switcher preview). On iOS 13+, it uses the UITextField.isSecureTextEntry trick to block screenshots and recordings, plus a separate blur overlay for the app switcher.

npx expo install expo-screen-capture

Enter fullscreen mode Exit fullscreen mode

// src/security/screenshot-prevention.ts

import * as ScreenCapture from "expo-screen-capture";
import { Platform } from "react-native";
import { useEffect, useRef } from "react";

/**
 * Prevents screenshots + recordings while the component is mounted.
 * Cleanup is automatic on unmount — other screens aren't affected.
 */
export function usePreventScreenCapture(key: string = "default"): void {
  useEffect(() => {
    ScreenCapture.preventScreenCaptureAsync(key);
    return () => {
      ScreenCapture.allowScreenCaptureAsync(key);
    };
  }, [key]);
}

/**
 * Maximum protection: blocks capture + blurs app switcher preview.
 * Use on payment, card details, OTP, and PIN screens.
 */
export function useSecureScreen(key: string = "default"): void {
  useEffect(() => {
    ScreenCapture.preventScreenCaptureAsync(key);
    if (Platform.OS === "ios") {
      ScreenCapture.enableAppSwitcherProtectionAsync(0.8);
    }
    return () => {
      ScreenCapture.allowScreenCaptureAsync(key);
      if (Platform.OS === "ios") {
        ScreenCapture.disableAppSwitcherProtectionAsync();
      }
    };
  }, [key]);
}

/**
 * Detect screenshot attempts for monitoring/logging.
 * Does NOT prevent — use alongside usePreventScreenCapture.
 */
export function useScreenshotDetection(onScreenshot: () => void): void {
  const callbackRef = useRef(onScreenshot);
  callbackRef.current = onScreenshot;

  useEffect(() => {
    const sub = ScreenCapture.addScreenshotListener(() =>
      callbackRef.current(),
    );
    return () => sub.remove();
  }, []);
}

Enter fullscreen mode Exit fullscreen mode

Use it on any sensitive screen — one line:

// src/screens/SecurePaymentScreen.tsx

function PaymentForm() {
  // Blocks screenshots, recordings, and app switcher preview (iOS + Android)
  useSecureScreen("payment-screen");

  // Log screenshot attempts to your SIEM
  useScreenshotDetection(() => {
    secureLog("Screenshot attempt on PaymentScreen");
    Alert.alert(
      "Screenshot Detected",
      "For your security, please avoid capturing screenshots of payment information.",
    );
  });

  // ... rest of the screen
}

Enter fullscreen mode Exit fullscreen mode

Platform coverage matrix:

Threat

Android

iOS

Screenshots

FLAG_SECURE

isSecureTextEntry trick (iOS 13+)

Screen recordings

FLAG_SECURE

Same mechanism

App switcher preview

FLAG_SECURE (automatic)

enableAppSwitcherProtectionAsync() (blur)

AirPlay / screen mirror

N/A

Blocked by capture prevention

Why per-screen, not app-wide: Blocking screenshots globally is hostile UX. Users should be able to screenshot their transaction history or support chat. Only block on screens showing card details, CVV, balances, payment confirmation, OTP entry, and PIN entry.

In the Demo App

Screenshot Prevention: Toggle protection on/off and take screenshots to see the difference. With protection disabled, your screenshot captures the full card number, CVV, and balance. Enable it, screenshot again — the capture is black. The detection counter increments each time. Background the app to see the app switcher blur.

PII Masking: The demo shows raw sensitive data (red block) next to the masked output (green block), field by field. Tokens, passwords, SSNs, and card numbers are replaced with *** plus last 4 characters. Non-sensitive fields like userName and email pass through unchanged.

Sentry/Crashlytics configuration for fintech:

// Don't send PII in crash reports
Sentry.init({
  beforeSend(event) {
    // Strip user data
    if (event.user) {
      delete event.user.email;
      delete event.user.ip_address;
    }
    // Strip sensitive breadcrumb data
    event.breadcrumbs = event.breadcrumbs?.map((b) => ({
      ...b,
      data: b.data ? maskSensitiveData(b.data) : undefined,
    }));
    return event;
  },
  beforeBreadcrumb(breadcrumb) {
    // Don't log network request bodies
    if (breadcrumb.category === "fetch" || breadcrumb.category === "xhr") {
      delete breadcrumb.data?.body;
      delete breadcrumb.data?.response_body;
    }
    return breadcrumb;
  },
});

Enter fullscreen mode Exit fullscreen mode

Checklist

• [ ] PII masking applied to all log outputs (console, Sentry, Crashlytics)
• [ ] Network request/response bodies stripped from crash reports
• [ ] useSecureScreen() on payment, card, OTP, and PIN screens (iOS + Android)
• [ ] App switcher blur enabled on iOS via enableAppSwitcherProtectionAsync()
• [ ] Screenshot detection logging to SIEM on sensitive screens
• [ ] Flipper and Reactotron disabled in production builds

---

M7: Insufficient Binary Protections

React Native's specific weakness: Your entire business logic ships as a JavaScript bundle (index.android.bundle / main.jsbundle). Without protections, anyone can extract and read it.

Real-World Incident: In 2022, the Lapsus$ group breached Samsung and leaked 190GB of source code — including device authentication logic, DRM modules, and Knox security platform source code. The leaked code was extracted, decompiled, and analyzed by attackers worldwide. Samsung confirmed the breach affected "source code relating to the operation of Galaxy devices" but stated no customer data was compromised. The damage, however, was done: proprietary security logic was now public, making targeted attacks on Samsung devices significantly easier. React Native apps face an even lower bar — your JavaScript bundle is essentially readable source code that can be extracted from any APK with unzip and a text editor, no sophisticated decompilation required.

Hermes bytecode compilation is the first line of defense. Hermes compiles JavaScript to bytecode at build time, making casual reverse engineering harder (not impossible, but significantly harder than reading plain JavaScript):

// app.json
{
  "expo": {
    "jsEngine": "hermes"
  }
}

Enter fullscreen mode Exit fullscreen mode

ProGuard/R8 for Android obfuscates the native Java/Kotlin layer:

// android/app/build.gradle
def enableProguardInReleaseBuilds = true

android {
    buildTypes {
        release {
            minifyEnabled enableProguardInReleaseBuilds
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
                         'proguard-rules.pro'
        }
    }
}

Enter fullscreen mode Exit fullscreen mode

Strip source maps in production: Source maps map bytecode back to your original TypeScript. Never include them in your production bundle:

// metro.config.js
const { getDefaultConfig } = require("expo/metro-config");

const config = getDefaultConfig(__dirname);

if (process.env.NODE_ENV === "production") {
  config.transformer = {
    ...config.transformer,
    minifierConfig: {
      compress: {
        drop_console: true, // Remove console.log statements
      },
    },
  };
}

module.exports = config;

Enter fullscreen mode Exit fullscreen mode

Disable debug mode in production: Verify that __DEV__ is false in production builds. Metro automatically sets this, but verify it:

if (__DEV__) {
  // This entire block is stripped from production bundles by Metro
  console.log("Debug mode active");
}

Enter fullscreen mode Exit fullscreen mode

Checklist

• [ ] Hermes engine enabled (bytecode compilation)
• [ ] ProGuard/R8 enabled for Android release builds
• [ ] Source maps uploaded to crash reporting service but NOT bundled in the app
• [ ] console.log statements stripped in production (drop_console: true)
• [ ] Debug mode verified as disabled in release builds

---

M8: Security Misconfiguration

Jailbreak/root detection without false-positives. Here's the problem: if you just check isJailBroken() and block the app, your Android developers with unlocked bootloaders can't test the app. So they add if (__DEV__) return false and forget to remove it. Or worse, they disable the check entirely.

The solution: a proper developer bypass that's architecturally impossible to trigger in production.

// src/security/jailbreak-detection.ts

import * as SecureStore from "expo-secure-store";

// jail-monkey provides native jailbreak/root detection
let JailMonkey: any = null;
try {
  JailMonkey = require("jail-monkey");
} catch {
  // Expected in Expo Go — works in production builds
}

export async function checkDeviceSecurity(): Promise<DeviceSecurityStatus> {
  const status: DeviceSecurityStatus = {
    isCompromised: false,
    isJailbroken: false,
    isRooted: false,
    isDebugged: false,
    reasons: [],
    devBypassed: false,
  };

  // Developer bypass — ONLY in __DEV__ builds (stripped by Metro in production)
  if (__DEV__ && (await isDevBypassEnabled())) {
    status.devBypassed = true;
    return status;
  }

  if (!JailMonkey) {
    if (!__DEV__) {
      status.isCompromised = true;
      status.reasons.push("Security module unavailable");
    }
    return status;
  }

  if (JailMonkey.isJailBroken()) {
    status.isCompromised = true;
    status.reasons.push(
      Platform.OS === "ios"
        ? "Device appears to be jailbroken"
        : "Device appears to be rooted",
    );
  }

  if ((await JailMonkey.isDebuggedMode()) && !__DEV__) {
    status.isCompromised = true;
    status.reasons.push("Debugger detected");
  }

  return status;
}

Enter fullscreen mode Exit fullscreen mode

The developer bypass system: The bypass token is stored in SecureStore and only checked when __DEV__ is true. Since __DEV__ is a compile-time constant that Metro sets to false in production builds, the entire bypass code path is dead-code-eliminated. Even if an attacker extracts and sets the bypass token, it has no effect in a production binary.

// src/security/jailbreak-detection.ts

const DEV_BYPASS_KEY = "fintech_dev_jailbreak_bypass";

export async function enableDevBypass(): Promise<void> {
  if (!__DEV__) {
    throw new Error("Dev bypass cannot be enabled in production");
  }
  await SecureStore.setItemAsync(DEV_BYPASS_KEY, "DEV_SECURITY_BYPASS_ACTIVE");
}

// Call from your dev menu:
// enableDevBypass().then(() => console.log('Bypass enabled'));

Enter fullscreen mode Exit fullscreen mode

Response strategy — don't just block: Different contexts warrant different responses:

export function getCompromisedAction(
  status: DeviceSecurityStatus,
  context: "payment" | "sensitive_data" | "app_launch" | "general",
): "block" | "warn" | "limit" | "allow" {
  if (status.devBypassed) return "allow";
  if (!status.isCompromised) return "allow";

  switch (context) {
    case "payment":
      return "block"; // Never allow payments on compromised devices
    case "sensitive_data":
      return "block"; // Block financial data viewing
    case "app_launch":
      return "warn"; // Warn but let user see non-sensitive features
    default:
      return "warn";
  }
}

Enter fullscreen mode Exit fullscreen mode

OTA update security: If you use expo-updates, verify that updates are signed and come from your server. A compromised OTA update can inject malicious code without going through App Store review.

In the Demo App

Tap "Scan Device" and watch each check run: native module loaded, jailbreak/root status, debugger detection, __DEV__ guard, and the resulting payment action (ALLOWED or BLOCKED). On a clean simulator you'll see all green. On a jailbroken device, the jailbreak row turns red and payments are blocked.

Checklist

• [ ] Jailbreak/root detection active in production builds
• [ ] Developer bypass uses __DEV__ guard (dead-code-eliminated in production)
• [ ] Graduated response: block payments, warn on general use
• [ ] OTA updates configured with code signing verification

---

M9: Insecure Data Storage

The AsyncStorage trap. I cannot stress this enough: AsyncStorage is not encrypted. It stores data as plaintext JSON files. On Android, it's in the app's shared preferences directory. On iOS, it's in the app's documents directory. A rooted device, an unencrypted backup, or a forensic extraction tool can read everything.

Here's a tiered storage strategy:

Tier 1 — Credentials (Keychain/Keystore): Use expo-secure-store for tokens, API keys, PII, and encryption keys. Backed by hardware encryption on devices with Secure Enclave (iOS) or StrongBox (Android).

Tier 2 — App data (encrypted MMKV): Use react-native-mmkv with an encryption key stored in Tier 1. 30x faster than AsyncStorage, and encrypted at rest.

// src/security/secure-storage.ts

import { MMKV } from "react-native-mmkv";
import * as SecureStore from "expo-secure-store";
import * as Crypto from "expo-crypto";

async function getOrCreateEncryptionKey(): Promise<string> {
  let key = await SecureStore.getItemAsync("fintech_encryption_key");

  if (!key) {
    // Generate 256-bit key with CSPRNG
    const randomBytes = await Crypto.getRandomBytesAsync(32);
    key = Array.from(new Uint8Array(randomBytes))
      .map((b) => b.toString(16).padStart(2, "0"))
      .join("");
    await SecureStore.setItemAsync("fintech_encryption_key", key, {
      keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
    });
  }
  return key;
}

export async function getEncryptedStorage(): Promise<MMKV> {
  const encryptionKey = await getOrCreateEncryptionKey();
  return new MMKV({
    id: "fintech-encrypted-storage",
    encryptionKey,
  });
}

Enter fullscreen mode Exit fullscreen mode

Tier 3 — Structured data (encrypted SQLite): For transaction history, contacts, etc., use expo-sqlite with column-level encryption. Encrypt sensitive fields before writing:

import { sha256 } from "./crypto-utils";

// Encrypt sensitive columns before storage
const encryptedName = await encryptForStorage(accountName, encryptionKey);
db.runAsync(
  "INSERT INTO accounts (id, name_encrypted, type) VALUES (?, ?, ?)",
  [accountId, encryptedName, accountType],
);

Enter fullscreen mode Exit fullscreen mode

What stays in AsyncStorage: Theme preference. Language selection. Whether the user has seen the onboarding carousel. That's it.

Checklist

• [ ] Tokens and PII in expo-secure-store (Keychain/Keystore)
• [ ] App data in encrypted MMKV with Keychain-stored encryption key
• [ ] Sensitive SQLite columns encrypted before storage
• [ ] AsyncStorage used ONLY for non-sensitive preferences
• [ ] redux-persist storage backend changed from AsyncStorage to SecureStore for auth state

---

M10: Insufficient Cryptography

Math.random() is not cryptographically secure. It uses a PRNG (Pseudo-Random Number Generator) seeded from system time. If you use it for transaction IDs, OTP generation, or anything security-sensitive, an attacker can predict the sequence.

Real-World Incident: In 2019, security researchers discovered that Twitter had been storing passwords in plaintext in internal logs — affecting all 330 million users. The passwords were written to logs before the hashing function was applied, meaning anyone with access to the log system could read them. Twitter urged all users to change their passwords. The root cause: the hashing step was in the wrong place in the pipeline. In the same vein, Adobe's 2013 breach initially reported 2.9 million credit card records stolen, but later analysis revealed 153 million user accounts were affected. The passwords were encrypted with 3DES in ECB mode — which preserves patterns, meaning identical passwords produced identical ciphertext — instead of properly hashed with bcrypt or Argon2. Security researchers could cross-reference the password hints with the repeated ciphertext blocks to crack millions of passwords without even breaking the encryption. Weak cryptography isn't just using the wrong algorithm; it's using the right algorithm in the wrong way. Math.random() for transaction IDs, SHA-1 for password hashing, or AES with a hardcoded key are all variations of the same mistake: cryptography that looks secure but isn't.

// ❌ WRONG — Predictable "random" IDs
const transactionId = Math.random().toString(36).substring(2);
const otp = Math.floor(Math.random() * 1000000)
  .toString()
  .padStart(6, "0");

// ✅ RIGHT — Cryptographically secure random
import * as Crypto from "expo-crypto";

export async function generateSecureHex(
  byteCount: number = 16,
): Promise<string> {
  const bytes = await Crypto.getRandomBytesAsync(byteCount);
  return Array.from(new Uint8Array(bytes))
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
}

export async function generateSecureId(length: number = 32): Promise<string> {
  const bytes = await Crypto.getRandomBytesAsync(length);
  const charset =
    "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
  return Array.from(new Uint8Array(bytes))
    .map((b) => charset[b % charset.length])
    .join("");
}

Enter fullscreen mode Exit fullscreen mode

Key derivation — PBKDF2, not bare hashing:

// ❌ WRONG — No stretching, vulnerable to brute force
const key = await sha256(userPin); // 4-digit PIN = 10,000 attempts

// ✅ RIGHT — Iterated key derivation with salt
export async function deriveKey(
  input: string,
  salt: string,
  iterations: number = 10000,
): Promise<string> {
  let derived = `${salt}:${input}`;
  for (let i = 0; i < iterations; i++) {
    derived = await Crypto.digestStringAsync(
      Crypto.CryptoDigestAlgorithm.SHA256,
      derived,
    );
  }
  return derived;
}

Enter fullscreen mode Exit fullscreen mode

Production note: The iterated SHA-256 approach above is a PBKDF2 approximation for environments where native PBKDF2 isn't available. For production, use react-native-quick-crypto which provides proper PBKDF2 with configurable iterations. OWASP 2024 recommends 600,000 iterations for PBKDF2-SHA256. In a pure expo-crypto environment, 10,000 iterations of SHA-256 is a reasonable floor.

In the Demo App

The Crypto Utils screen puts Math.random() and CSPRNG side by side. Tap "Generate 5 Random Values" — the left column (red) shows predictable PRNG output, the right column (green) shows hardware-backed random bytes. Below that, type any text and hash it with SHA-256 in real time. The key derivation demo shows the intentional delay — tap "Derive Key from PIN 1234" and watch it take 100+ milliseconds for 1000 iterations.

Checklist

• [ ] Math.random() never used for security-sensitive values
• [ ] All random generation uses expo-crypto CSPRNG
• [ ] Key derivation uses iterated hashing with salt (PBKDF2 or equivalent)
• [ ] No MD5 or SHA1 usage anywhere in the codebase
• [ ] Encryption keys generated with CSPRNG and stored in Keychain/Keystore

---

The Full Checklist

Print this. Tape it to your monitor. Check every item before submitting for security review.

Control

Action

Status

M1

Credential Storage

Tokens in Keychain/Keystore via expo-secure-store, not AsyncStorage

M1

Session Timeout

5-min inactivity + 2-min background timeout enforced

M2

Supply Chain

npm audit in CI, exact versions for security packages

M2

Dependency Review

Native module permissions reviewed before adding packages

M3

Biometric Auth

Gates on all sensitive screens, not just login

M3

Auth Fallback

Max attempt limits, tested on real devices

M4

SQL Injection

Parameterized queries for all SQLite operations

M4

Deep Links

Validated against scheme/host allowlist

M4

Input Validation

Amount range, precision, and format checks for payments

M5

SSL Pinning

Public key hash pinning with 2+ pins (current + backup)

M5

Cert Rotation

expirationDate safety valve + rotation plan documented

M6

PII in Logs

Sensitive fields masked in all log outputs

M6

Crash Reports

Request/response bodies stripped from Sentry/Crashlytics

M6

Screenshots

useSecureScreen() via expo-screen-capture on iOS + Android

M7

Hermes

Bytecode compilation enabled

M7

ProGuard

R8/ProGuard enabled for Android release builds

M7

Source Maps

Stripped from production bundle, uploaded to crash service only

M7

Debug Mode

console.log stripped, __DEV__ verified false in release

M8

Jailbreak

Detection active with developer bypass via __DEV__ guard

M8

Response Strategy

Graduated: block payments, warn on general use

M8

OTA Security

Code signing verification for expo-updates

M9

Tier 1 Storage

Credentials in Keychain/Keystore

M9

Tier 2 Storage

App data in encrypted MMKV

M9

Tier 3 Storage

SQLite with column-level encryption

M9

AsyncStorage

Used ONLY for non-sensitive preferences

M10

CSPRNG

expo-crypto for all random generation

M10

Key Derivation

Iterated SHA-256 with salt (or PBKDF2 via quick-crypto)

M10

No Weak Crypto

No MD5, no SHA1, no Math.random() for security

---

What a Security Audit Actually Looks For

I've worked with pen testing teams on RN apps. Here's what they check first — in order:

1. Network traffic interception. They install a proxy (Burp Suite, mitmproxy) on a rooted device with a custom CA certificate. If they can see plaintext API traffic, that's a critical finding. SSL pinning stops this — it's the first thing they test.

2. Local data extraction. They pull the app's data directory from a rooted device and search for tokens, PII, and financial data in plaintext. AsyncStorage is the first place they look. Shared preferences is second. If your tokens are in either, that's another critical.

3. Binary analysis. They extract the APK/IPA, unzip it, and examine the JavaScript bundle. They search for hardcoded API keys, endpoint URLs, secret keys, and validation logic. Hermes bytecode makes this harder but not impossible — tools like hermes-dec can decompile Hermes bytecode back to readable JavaScript.

4. Runtime manipulation. On a jailbroken device, they use Frida or Objection to hook into your app at runtime. They can bypass biometric checks, modify function return values, and intercept encrypted data before it's encrypted. Jailbreak detection catches this scenario — or at least makes it harder and shows your auditors you're trying.

5. Debug artifacts and extraneous functionality. They look for hidden API endpoints, debug parameters (?isAdmin=true — see the Peloton incident above), console logging in production, and leftover test screens. They'll also check if Flipper, Reactotron, or the React Native dev menu is accessible in your release build.

Tools they'll use against your app:

Tool

What It Does

What It Finds

MobSF

Static + dynamic analysis

Exported components, hardcoded keys, insecure storage

Frida

Runtime hooking

Bypass biometrics, modify function returns, intercept decrypted data

Objection

Runtime exploration (built on Frida)

Dump Keychain, bypass SSL pinning, explore the filesystem

Burp Suite

HTTP proxy + scanner

API vulnerabilities, missing pinning, auth bypass

Jadx / hermes-dec

Decompiler

Hardcoded secrets, business logic, API endpoints in your bundle

Drozer

Android IPC testing

Exposed Intents, Content Providers, Broadcast Receivers

Beyond build-time protection — RASP: Consider deploying Runtime Application Self-Protection (RASP) for your highest-security flows. Unlike jailbreak detection which checks once at launch, RASP monitors continuously for code injection, function hooking (Frida), debugger attachment, and memory tampering. Tools like Talsec freeRASP provide a React Native SDK. This doesn't replace the controls in this article — it adds a real-time detection layer on top of them.

The common thread: pen testers assume a rooted/jailbroken device. They assume the attacker has physical access. They assume the network is hostile. Your security controls need to hold up under all three assumptions simultaneously.

---

Conclusion

Security in React Native fintech isn't one big thing — it's 30 small things done right. No single control is sufficient. SSL pinning without secure storage is pointless (the attacker reads the token from disk). Secure storage without session timeout is pointless (a stolen token works forever). Biometric auth without jailbreak detection is pointless (Frida bypasses it in 5 minutes).

The code in this article is real, tested, and production-ready. Every file exists in the companion repo with full implementations. Clone it, adapt it to your domain, and use the checklist above as your pre-audit scorecard.

If you're about to go through a security audit for your RN fintech app, start with M1 (credential storage) and M5 (SSL pinning). Those two controls address the most common critical findings. Then work through the rest of the list. Your pen testers will thank you — or at least, they'll have to work harder to find something.

Companion repo: github.com/FastheDeveloper/owasp-rn-fintech

---

Built with expo-secure-store@15.x, expo-crypto@15.x, expo-local-authentication@17.x, react-native-ssl-public-key-pinning@1.2.x, react-native-mmkv@4.x, and jail-monkey@3.x.