Skip to content

Instantly share code, notes, and snippets.

@dougg0k

dougg0k/REACT_NATIVE_SECURITY.md

Last active December 8, 2025 20:18
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save dougg0k/60e02f2fd99df129a7e329c92309fd5e to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save dougg0k/60e02f2fd99df129a7e329c92309fd5e to your computer and use it in GitHub Desktop.
Download ZIP
React Native Security - this compilation were initially built upon a help request about security for a banking app.
Raw
REACT_NATIVE_SECURITY.md

Obfuscate code helps.

Jailbreak / rooted / emulator checks, close app if detected.

Runtime App Self Protection (RASP)

Require app updates, as to not support older versions. Having checks in place.

Integrity checks

Disable any sort of debugging.

To store auth tokens and others.

Do all things in the backend. The App / Web should be only for displaying data and taking action on it for the most part.

  • You can make use of Paseto (auth token) in the backend.
  • By using Paseto, you can have two things, a less vulnerable alternative to JWT for authentication, and verification of the payload with it's private / public key, similarly as HMAC Signature intent, helps ensure the integrity of the data being transported.
  • Make use of refresh token and access token pattern, where refresh token only serves to refresh the access token which should have duration of minutes, and access token to request content only.
  • Use argon2 for password hashing.
  • Never return database error messages or data that may be sensitive, in errors from API responses, that should be logged / reported to the developer, to be fixed. The frontend should only know that an error happened and the admin or developer are aware, but validation error messages can be returned.
  • You can opt to use multiple login types (MFA - Multi Factor Auth), no password might be safer, so there is OTP auth as option, be through email, SMS or some other messaging tool to receive the code.
    • 2FA can be an additional security option. HOTP or TOTP.

Device Binding

  • You could send specific information from the smartphone like a combined string uniqueDeviceId + deviceManufacturer + model and tie the auth token to it. That way, it cannot be used in another device.
  • You can session limit with device binding. Like one device at the time or more.

SSL Pinning - though there is Public Key Pinning, and it might be a better option.

Biometrics could help make it more difficult.

Hardware keys / Passkeys, but this would be something optional like 2FA is in some cases.

For encryption work, I would say to do in the backend, but if not possible.

No logging on release.

Input Sanitization / Validation

Keep RN and dependencies updated.

  • Use only the best options (most used) available and keep to a minimum.
  • Have something in place to auto-upgrade the packages and do code upgrades if major changes are needed.
  • Use tools like pnpm or yarn latest versions for further install protections.

Disable recording / screenshot in the app.

Have app signature verification.

  • While the integrity options above are a way to check, it's not the same.
  • Currently, this might require some manual work on the native side. As well as managing generated certs. Since currently, there is no good library for this.
  • Always combine with backend checks where possible, not only on the client-side, since that can be bypassed.
  • You can generate checksum or certs based manually through the CI for both native and jsbundles. But it takes more work. And probably would require some other implementation natively and in js.
  • There is this library react-native-app-integrity-checksum but it is very outdated has too many dependencies, seems like a bad package, not recommended.

https://github.com/bamlab/react-native-app-security - Mix of checks, left it here, but other standalone options are likely better.

Never use deep links for sensitive data.

No sensitive env vars in the frontend/app.

  • But there is a safer option than react-native-config and react-native-dotenv, that can help env vars that are not possible to have the setup in the backend - https://github.com/numandev1/react-native-keys
    • Currently react-native-keys still has ways to go to be free of vulnerabilities. But at this point it's the safer option.

Have CI dependency vulnerabilities verification checks with snyk or some other tool.

Develop native functionality in a single point rather than in Java/Kotlin and ObjC/Swift, this way it can help prevent bugs and even security issues.

OWASP

OTA

  • It could help provide faster hotfixes in case some security issue are discovered or bad impl are done. It's on the JS side only.
  • https://github.com/gronxb/hot-updater - This tool seem to be working to be more than that.

Lint / Types

  • Lint are recommended due to it's checks which can help prevent security issues.
  • Types are recommended with Typescript, with proper configuration, you can enforce additional good practices, therefore having less bugs, so leading to less security issues.
  • All should be enforced in both dev environment and CI.

Tests

For the backend, if starting something new, I would recommend Rust or DenoJS which are rust-based, both are likely to have less vulnerabilities. Just my opinion though.

  • Your data is a secure as you made your backend to be. In all ends of it.
    • OS always keep to a minimum in packages, always updated.
    • There are hardened kernels and many things that can be done to increase security in the OS part.
    • API preferably containerized.
    • Everything isolated and harder to access, with strict configurations, and so on. And not just what you or someone else know, but researched and updated config to latest and safest approaches.
    • Ideally ALL should be automated, to have predictable actions done to the server, as to prevent things done by someone, where someone else would not know about it. Everything stored in a repo / commited, of course.
  • If not starting new, and there is a legacy system that requires scaling and need a rewrite, Rust can be a great alternative too.

There are other things, that can also help, but those are more specific things like configurations, those you should search by yourself.

  • One example being related to android apk signing, only v4 being free of known vulnerabilities.
  • Fstack Protector
    • In ios (xcode), select the target in the Targets section, then click the Build Settings tab, make sure that the -fstack-protector-all option is selected in the Other C Flags section and that Position Independent Executables (PIE) support is enabled.
    • In android, android/build.gradle in one of the build configurations, make sure that cmake > cppFlags has -fstack-protector-all as one of it's setting.

Like everything else, it's your responsibility to confirm whether your implementation are working by adding checks / doing security analysis.

Be sure to check each package before using.

Some additionals suggestion by Gemini 2.5 - https://pastebin.com/raw/uyaeKjsr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment