React Native Security Checklist, Based on OWASP MASVS

Every copy of your React Native app carries its JavaScript bundle to the user's phone, and anyone can unzip an APK or IPA and read what's inside. Hermes bytecode makes that slightly less convenient, not impossible. So mobile security starts with an uncomfortable assumption: an attacker can see everything in your app, change it and replay any request it makes.

The OWASP Mobile Application Security Verification Standard (MASVS) organises mobile security into eight control groups. This checklist maps React Native security best practices onto each one, with the specific libraries, settings and mistakes that matter in a React Native or Expo app, plus what compliance-aware builds need on top.

Key takeaways

• Assume the client is compromised. Every secret in the bundle is public, and every check that matters must happen on the server.
• Store tokens in the Keychain or Keystore, never in AsyncStorage or unencrypted local storage.
• EXPO_PUBLIC_ variables are visible in the compiled app. Never put secrets in them.
• Harden the platform edges: deep links, WebViews, backups and screenshots of sensitive screens.
• Use resilience measures (root detection, attestation, obfuscation) for high-risk apps, as extra layers on top of server-side checks.
• Privacy is part of security: collect less, declare it accurately and let users delete their data.

Start with a threat model

Before the checklist, spend an hour on three questions. What's valuable in your app (accounts, money, health data, personal documents)? Who might attack it (opportunistic fraudsters, curious users, competitors, targeted attackers)? And what would a breach cost you and your users? A habit tracker and a banking app need very different depth. The OWASP project also publishes testing profiles for that reason: baseline security for every app, and stronger defence-in-depth and resilience testing for apps handling sensitive data.

MASVS-STORAGE: data on the device

• Tokens and secrets go in secure storage: expo-secure-store or react-native-keychain, backed by the iOS Keychain and Android Keystore.
• Encrypt sensitive local databases, with the key kept in secure storage, not in code.
• Exclude sensitive files from backups and clear user data on sign-out.
• Hide sensitive screens from screenshots and the app switcher (for example, with expo-screen-capture on Android and a privacy overlay when the app goes to the background).
• Keep sensitive data out of logs, including crash reports and analytics events.

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

await SecureStore.setItemAsync("refreshToken", token, {
  keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
});

MASVS-CRYPTO: secrets and cryptography

• No secrets in the bundle. API keys for services that charge money or expose data belong on your server. Expo's documentation is explicit that EXPO_PUBLIC_ variables are embedded in the compiled app in plain text.
• Don't write your own cryptography. Use platform APIs or well-reviewed libraries, and secure random number generation.
• Never hard-code encryption keys. Generate them on the device and keep them in the Keychain or Keystore.

MASVS-AUTH: authentication and authorisation

• Authorise every request on the server. Hiding a button in the app protects nothing.
• Use OAuth with PKCE through the system browser for third-party sign-in, rather than embedded WebViews.
• Keep access tokens short-lived and refresh tokens revocable on the server.
• Bind biometrics to a Keychain or Keystore item rather than trusting a simple "biometric check passed" result, which a compromised device can fake.
• Rate-limit sign-in, password reset and verification codes, and alert on unusual patterns.

MASVS-NETWORK: data in transit

• HTTPS everywhere. iOS App Transport Security and Android's default block on cleartext traffic for modern target SDKs enforce this; don't add exceptions casually.
• Don't trust user-installed certificates in release builds (Android's default for current target SDKs).
• Consider certificate or public key pinning for high-risk apps, with a plan for key rotation, because a pinning mistake can lock every user out of your API.

MASVS-PLATFORM: deep links, WebViews and permissions

• Validate every deep link parameter as untrusted input, and prefer Universal Links and Android App Links over custom URL schemes for sensitive flows.
• Lock down WebViews: restrict allowed origins, disable JavaScript where you don't need it, never inject untrusted data, and don't expose native bridges to remote content.
• Request only the permissions you use, at the moment you need them.
• Review exported Android components and intent filters added by libraries.

MASVS-CODE: code quality and dependencies

• Keep dependencies updated with Dependabot or Renovate, and review new packages before adding them.
• Scan for secrets in the repository and CI logs.
• Validate API responses at the edge, so malformed data can't crash the app or reach unsafe code paths.
• Strip debug features from release builds: dev menus, verbose logging and test endpoints.
• Stay on supported React Native and Expo versions, so you receive security fixes.

MASVS-RESILIENCE: tampering and reverse engineering

For banking, health, gambling or apps with valuable digital goods, add layers that raise an attacker's cost:

• Root and jailbreak detection, used to adjust risk (for example, require extra verification) rather than as a hard block.
• App attestation with Apple's App Attest and Google's Play Integrity API, verified on your server.
• Obfuscation of native code and sensitive logic.

None of these stops a determined attacker on their own. They complement server-side checks; they never replace them.

MASVS-PRIVACY: collect less, declare it honestly

• Minimise data collection and keep personal data out of third-party SDKs where possible.
• Declare data use accurately in Apple's privacy details, the iOS privacy manifest and Google Play's Data safety form.
• Ask for tracking consent where required, and respect it across analytics and ads.
• Offer account deletion inside the app, which both stores require for apps with account creation.

From the field: I build OWASP-aligned and SOC 2, HIPAA and PCI-aware mobile and web apps. On Expetitle, a real estate closing platform later acquired by The Real Brokerage (NASDAQ: REAX), that meant RBAC, audit trails, encrypted storage and careful PII handling. Across 12+ apps with payments (Stripe, RevenueCat, in-app purchases, Razorpay and KNET), billing is idempotent and webhook-driven.

Compliance-aware builds

• PCI DSS: use your payment provider's mobile SDK or hosted pages so raw card numbers never touch your servers, keeping your compliance scope as small as possible.
• HIPAA: sign business associate agreements with vendors that handle protected health information, and scrub health data from logs, crash reports and analytics.
• SOC 2: expect questions about access control, change management, logging, vendor management and incident response, for the app and the backend alike.

Common React Native security vulnerabilities

The issues that turn up most often in real React Native apps:

• Secrets in the bundle: API keys for paid services or admin endpoints shipped in JavaScript or EXPO_PUBLIC_ variables.
• Tokens in plain storage: refresh tokens in AsyncStorage or unencrypted files.
• Unvalidated deep links that navigate to sensitive screens or trigger actions.
• WebViews loading untrusted content with JavaScript and native bridges enabled.
• Outdated dependencies with published vulnerabilities.
• Trusting the client: prices, roles or permissions decided in the app instead of on the server.
• Personal data in logs and crash reports.

Security checkers worth running

• MobSF (Mobile Security Framework): open-source static and dynamic analysis of your built APK or IPA, which catches insecure settings, exposed components and hard-coded secrets.
• Dependency scanning: npm audit, Dependabot or Snyk in CI, so known vulnerabilities in packages are flagged on every pull request.
• Secret scanning: in the repository and CI logs, before a key reaches a build.

How to verify it

1. Run the checklist above as part of every major release, not once.
2. Use the OWASP MASTG (the testing guide that accompanies MASVS) to test specific controls.
3. Automate what you can: dependency and secret scanning in CI, plus static analysis of release builds.
4. Commission a mobile penetration test before launch for apps handling money or sensitive data, and after major changes.

FAQ

Is React Native secure?

React Native can be as secure as a native app when it's built with the same care: secrets on the server, tokens in the Keychain or Keystore, server-side authorisation, hardened deep links and WebViews, current dependencies and accurate privacy declarations. The framework isn't the weak point; assumptions about the client usually are.

Can people see my React Native source code?

They can see your JavaScript bundle. It ships inside every copy of the app and can be extracted, and Hermes bytecode can be decompiled. Treat everything in the bundle, including EXPO_PUBLIC_ environment variables, as public, and keep secrets and sensitive logic on the server.

Where should I store tokens in a React Native app?

In the device's secure storage, the iOS Keychain and Android Keystore, through libraries such as expo-secure-store or react-native-keychain. Don't use AsyncStorage or unencrypted storage for tokens, and keep access tokens short-lived.

Do I need certificate pinning in my app?

Not always. HTTPS with platform defaults protects most apps. Pinning adds protection against interception for high-risk apps such as banking, but it needs careful key rotation planning, because a mistake can block every user from your API.

Next steps

If you want a security review of your React Native app against MASVS, or need to prepare for a penetration test or a compliance audit, I can help. Get in touch, or see my services.

Sources

• OWASP MASVS, OWASP
• OWASP MASTG, OWASP
• Mobile Security Framework (MobSF), GitHub
• Security, React Native docs
• Environment variables in Expo, Expo documentation
• Privacy manifest files, Apple
• Network security configuration, Android Developers