1 Audit Your Dependencies Quick

Run npm audit (or yarn npm audit on Yarn Berry, yarn audit on Yarn Classic) or our scanner. A match means an installed version falls inside a published advisory's affected range. It does not show that your app uses the vulnerable code.

Prioritize by:

Whether the affected package ships in your app or only runs in build tooling
Whether the vulnerable code is reachable, for example with untrusted input
Evidence of exploitation, such as the CISA Known Exploited Vulnerabilities catalog, not severity alone. CVSS measures severity, not risk.

Start Here

npm audit fix updates what it can within your version ranges. npm's docs note that some vulnerabilities need manual intervention, and fixes outside your ranges need --force, so test before shipping. npm audit does not cover native CocoaPods or Gradle dependencies.

2 Keep Privileged Secrets Off the Device Involved

Anything shipped in the app can be extracted: JavaScript, .env values bundled at build time, Info.plist, strings.xml, and native code. The React Native docs say never to store sensitive API keys in app code, because anyone inspecting the app bundle can read them.

Check for:

Secret keys for third-party services, admin credentials, or signing keys anywhere in the repo or build config
.env files read by react-native-config or similar tools that contain secrets
Secrets that were ever committed to git history; rotate them, deleting the file isn't enough

react-native-config does not hide secrets.

Its README says it doesn't obfuscate or encrypt secrets and warns not to store sensitive keys in .env. It is for configuration such as API endpoints. Moving a secret into it leaves the secret in the shipped app.

Fix

Move privileged secrets to a backend you control that calls the third-party service for the app, and give the app short-lived, per-user tokens instead. Identifiers that must ship in the app should be restricted on the provider's side to the minimum permissions they need.

3 Store User Tokens in Platform Secure Storage Moderate

Per-user credentials issued at runtime, such as OAuth access and refresh tokens, do belong on the device, but not in AsyncStorage. The React Native docs describe Async Storage as unencrypted and say not to use it for tokens.

Don't store in AsyncStorage:

Access tokens, refresh tokens, or session identifiers
Passwords or other user credentials
Other sensitive personal data your threat model covers

Fix

Use storage backed by the iOS Keychain and the Android Keystore, such as react-native-keychain or expo-secure-store. Android's EncryptedSharedPreferences library was deprecated in androidx.security:security-crypto 1.1.0 in favor of using Android Keystore directly, so check what your storage library uses. Keep tokens out of logs and crash reports. Secure storage protects user tokens on the device; it is not a place to hide secrets shipped with the app.

4 Enforce HTTPS, Then Decide on Pinning Moderate

Start with transport security everyone needs. iOS App Transport Security requires HTTPS for URLSession connections by default, and Android 9 and later disable cleartext traffic by default. Check that release builds carry no ATS exceptions or cleartextTrafficPermitted settings meant for local development.

Certificate pinning is a threat-model decision, not a default:

Apple says pinning is not required and, in most cases, should be avoided.
Android says certificate pinning is not recommended for Android apps, because server certificate changes can lock out users until they update.
OWASP's MASWE-0028 (Insecure Identity Pinning), which maps to MASVS-NETWORK-2, is tagged for the higher-assurance L2 profile, and notes that attackers can remove, modify, or bypass pins on a device they control.

If your threat model calls for pinning

Pin public keys rather than individual certificates, include backup pins with at least one key fully in your control, prefer platform configuration (Android Network Security Config, iOS NSPinnedDomains) or a maintained library, and write down how you'll rotate keys and ship updated pins before any certificate change.

5 Ship Release Builds Without Debug Surfaces Quick

Debug configurations enable developer tooling and often relax network rules to reach the local dev server. Make sure none of that reaches production.

Verify in release builds:

Builds use the release configuration, so __DEV__ is false and the dev menu is unavailable
Cleartext or ATS exceptions exist only in debug configuration
Logs don't print tokens, personal data, or full API responses (for example, strip console calls with babel-plugin-transform-remove-console)
On projects older than React Native 0.74, which removed the Flipper React Native plugin, Flipper is limited to debug builds

6 Treat Root and Jailbreak Detection as Resilience Only Involved

Local root and jailbreak checks can be bypassed. OWASP's testing guide says root detection "is not very effective by itself," and OWASP MASVS says the absence of these measures is not in itself a vulnerability. They matter for apps whose threat model includes tampering, fraud, or abuse.

If you need device integrity signals

Use attestation your server verifies: the Play Integrity API on Android and App Attest on iOS. Apple notes that an app can't reliably check itself, because a compromised app can falsify the results. SafetyNet Attestation was fully turned down in January 2025. Libraries such as jail-monkey can add a local signal, but never gate security decisions on them alone.

7 Review Deep Link Handling Moderate

The React Native docs say deep links are not secure and should never carry sensitive information. Treat every parameter as untrusted input.

Check:

Validate all deep link parameters before use
Never sign a user in or perform a sensitive action from link data alone
Don't load URLs from links into WebViews that expose native functionality
Prefer verified links (Android App Links, iOS Universal Links) for flows that matter, and use PKCE for OAuth redirects

About Obfuscation

Obfuscation is defense in depth, not a security boundary. OWASP MASVS says it must not be used as a substitute for proper security architecture. R8 shrinks and obfuscates Android Java and Kotlin code, but not your JavaScript bundle. Hermes bytecode can be turned back into readable code with tools listed in the OWASP testing guide.

Bitcode is not an obfuscation control and is obsolete: since Xcode 14, Xcode no longer builds bitcode by default and the App Store no longer accepts bitcode submissions. If an old guide tells you to enable it, skip that step.

React Native Security Checklist