Many React Native apps neglect security. The result? Apps full of basic flaws that can be easily exploited. Working with real apps, I found problems ranging from simple oversights to risky practices:
- Using AsyncStorage for sensitive information - Storing API Keys or authentication tokens in AsyncStorage is like writing your password on a post-it and leaving it on the screen. AsyncStorage was not made for secrets.
- Exposing unnecessary data on the client - Many apps load data that the user doesn't need to see, increasing the attack surface.
- console.log revealing sensitive information - Logs of tokens, request data, or API errors should never go to production.
- Disabling HTTPS for HTTP endpoints - Without HTTPS, any attacker can intercept traffic and steal information.
- Tokens and keys without expiration - A token that never expires is like a key that opens your house forever. If leaked, the attacker will have indefinite access.
- Too much logic on the client - Critical business rules on the client can be manipulated. The server should always decide if an action is valid.
- Incorrect input validations - The client should never be the final responsible for validation. Without server validation, any manipulated payload can cause problems.
And so on...
Why does this happen?
Most of the time, it's not a matter of bad faith or lack of will. One of the problems is delivery rush or the famous "we'll see later". The consequence is that the client becomes a ticking time bomb: small flaws accumulate and, sooner or later, can be exploited, causing damage to users and companies.
In this article, I intend to cover some best practices and questions I've seen in interviews about security in RN apps. Even being hybrid, we can still use native methods to strengthen security.
Essential React Native security checklist
To keep your app secure, pay attention to these points:
- Secure storage: use Keychain (iOS) or Keystore (Android), never AsyncStorage for secrets.
- Secure communication: HTTPS mandatory, with certificate validation.
- Clean logs: never expose sensitive data in
console.log. - Less data on the client: load only what's necessary. Critical data stays on the server.
- Tokens and keys: always with expiration and revocation mechanism.
- Business rules on the server: the client sends requests but doesn't decide critical results. It's essential to keep the minimum number of business rules on the client side.
- Mobile validations: should be done on the client to improve user experience, but the server should always be the final authority.
- Additional protections: code obfuscation, integrity checking, and protection against reverse engineering.
Advanced topics that come up in interviews
If you want to prepare for interviews at fintechs, banks, or sensitive apps, it's worth knowing:
- OWASP Top 10: the ten most common flaws in apps, including mobile.
- SAST (Static Application Security Testing): code analysis without running the app to identify flaws.
- DAST (Dynamic Application Security Testing): tests with the app running simulating real attacks.
- DexGuard / ixGuard: code protection against reverse engineering. DexGuard is for Android, ixGuard for iOS.
- SonarQube / SonarCloud: tools that identify security and quality problems in code.
- Communication security and cryptography: Encryption of sensitive data in transit and at rest.
Conclusion
Security in React Native is not optional. It should be present in all stages of development.
An insecure app is not just a bug: it's a real risk for users and companies. If you want to work at fintechs, banks, or any app that deals with sensitive data, mastering these practices is mandatory and you will become an excellent mobile developer.