Short answer: Keep secrets and business logic on the server, store tokens only in the iOS Keychain or the Android Keystore, verify every API call server-side, and run dependency, secret and static-analysis scans on every build. OWASP MASVS is the standard checklist, and an app that holds personal data of Israeli users also falls under the Privacy Protection Law and its 2017 data security regulations.
Key takeaways
- Start from MASVS: version 2 of the OWASP standard groups mobile requirements into eight areas, from storage and cryptography to network, privacy and resilience.
- Credentials top the risk list: improper credential usage is M1 in the OWASP Mobile Top 10 2024, followed by inadequate supply chain security.
- Pinning needs a backup plan: Android's documentation says to always include a backup key, otherwise a certificate change forces an app update to restore connectivity.
- Israeli enforcement got stronger: Amendment 13 to the Privacy Protection Law took effect on 14 August 2025 and lets the Privacy Protection Authority impose financial sanctions.
What the OWASP standards cover
MASVS is the requirement list; the Mobile Top 10 is the risk ranking. MASVS has eight control groups: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY. A reasonable baseline for a business app is to pass the first four in full, then add RESILIENCE (root and jailbreak detection, tamper checks) when the app moves money or holds identity documents, as in most fintech software projects.
Storage, network and API authentication
| Control | What to do | Common mistake |
|---|---|---|
| Secure storage | Tokens in Keychain or Keystore (for example expo-secure-store in React Native) | Tokens in AsyncStorage or SharedPreferences as plain text |
| Transport | TLS everywhere; Android 9 and later block cleartext traffic by default | Debug settings that allow HTTP in release |
| Certificate pinning | Pin public keys, with a backup pin and a rotation plan | Pinning one leaf certificate that will expire |
| API authentication | Short-lived tokens, permissions checked on the server for every request | Trusting a user ID or role sent by the app |
| Secrets | Third-party keys stay on a backend proxy | A payment or AI provider key inside the app binary |
Anything inside the binary can be extracted, and obfuscation only slows an attacker down. Permission logic belongs on the server as well; the pattern is covered in roles and permissions for SaaS apps.
