Encrypting sensitive data is the right instinct, but encryption only protects you if the cryptography is sound. Plenty of apps encrypt and still leave data exposed, because they use a broken algorithm, implement a good one incorrectly, manage keys poorly, or invent their own scheme. OWASP captures this as M10, Insufficient Cryptography, in its Mobile Top 10: the risk is not the absence of cryptography but cryptography that does not actually protect what it is supposed to. It is a subtle category, because the app looks like it is doing the secure thing while the protection is hollow. Here is what M10 covers and how to address it.
Short answer
M10, Insufficient Cryptography, is the OWASP Mobile Top 10 risk that an app uses cryptography that fails to protect data, through weak or outdated algorithms, incorrect implementation of strong algorithms, insufficient key lengths, poor key management, or home-grown schemes. Per OWASP, the consequence is that data the app appears to protect can be decrypted or recovered by an attacker, despite encryption being present. The defenses are to use current, strong, standard algorithms with adequate key lengths, implement them correctly using vetted platform libraries rather than custom code, manage keys properly, including keeping them out of the binary and in secure storage, and avoid inventing your own cryptography. Sound cryptography, correctly implemented, is what makes encryption mean something.
What you should know
- M10 is about cryptography that fails to protect: not its absence.
- Weak algorithms and key lengths: outdated or inadequate choices.
- Incorrect implementation: a strong algorithm used wrongly.
- Poor key management: hardcoded or badly stored keys.
- Home-grown cryptography: custom schemes instead of vetted ones.
What is M10: Insufficient Cryptography?
It is the risk that an app's cryptography does not provide the protection it implies. An app can use encryption and still be vulnerable if the cryptography is insufficient in any of several ways: the algorithm is weak or obsolete and can be broken, a strong algorithm is implemented incorrectly so its guarantees do not hold, the key is too short or poorly chosen, the keys are managed badly, hardcoded in the binary or stored insecurely, or the developer has rolled their own cryptographic scheme instead of using an established one. In all of these, the app presents the appearance of protection while the actual confidentiality or integrity is compromised, which is what makes M10 distinct from simply not encrypting: the gap is hidden behind code that looks secure. Because so much of an app's other security, stored secrets, protected data, authentication tokens, ultimately rests on cryptography being sound, insufficient cryptography can quietly undermine protections elsewhere. M10 treats the correctness and strength of cryptography as the asset, not merely its presence.
How does cryptography fall short?
In a handful of recurring ways. The table lists them.
| Failure | What it looks like |
|---|---|
| Weak or outdated algorithm | An obsolete cipher or hash that can be broken |
| Insufficient key length | A key too short to resist attack |
| Incorrect implementation | A strong algorithm used in an insecure mode or way |
| Poor key management | Hardcoded keys or insecure key storage |
| Home-grown cryptography | A custom scheme instead of a vetted standard |
The clearest failure is choosing a weak or outdated algorithm, an obsolete cipher or a broken hash function, that an attacker can defeat regardless of how carefully it is used. Closely related is an inadequate key length, where even a sound algorithm is undermined by a key short enough to attack. More subtle is incorrect implementation: a strong algorithm used in an insecure mode, with a predictable or reused initialization value, or otherwise applied wrongly, can lose its guarantees while appearing to work. Key management is its own failure mode, a perfectly good algorithm protects nothing if the key is hardcoded in the app or stored where it can be read. And home-grown cryptography, a scheme the developer invented rather than a vetted standard, is almost always weaker than it looks. Each leaves the appearance of protection without the substance.
How do you address M10?
Use strong, standard cryptography correctly, and manage keys properly. Choose current, well-regarded standard algorithms with adequate key lengths, and avoid obsolete ciphers and broken hash functions, following established guidance on what is currently considered strong rather than older defaults. Implement cryptography using your platform's vetted cryptographic libraries rather than writing your own, since the libraries handle modes, initialization values, and other details that are easy to get wrong, and never invent your own cryptographic scheme. Use algorithms correctly, an appropriate mode, unique and unpredictable initialization values where required, and the right primitive for the job. Manage keys with care: do not hardcode keys in the binary, generate and store them using the platform's secure facilities such as the Keychain or Keystore, ideally hardware-backed, and rotate them where appropriate. And lean on the platform's high-level cryptographic APIs, which encode many of these decisions safely. The principle is that encryption is only as good as the algorithm, the implementation, and the key management behind it, so get all three right rather than assuming that encrypting at all is sufficient.
What to watch out for
The first trap is assuming that because the app encrypts, the data is safe, when a weak algorithm, short key, or flawed implementation leaves it recoverable. The second is poor key management, hardcoding a key or storing it insecurely, which nullifies otherwise sound cryptography. The third is home-grown cryptography, which tends to be weaker than vetted standards. A pre-submission scan such as PTKD.com (https://ptkd.com) is well suited to parts of M10: it reads the compiled app against OWASP MASVS and surfaces weak cryptographic usage and hardcoded keys, the kind of insufficient-cryptography signals visible in the binary, so you can correct the algorithm, key handling, or implementation before release.
What to take away
- M10, Insufficient Cryptography, is the OWASP Mobile Top 10 risk that an app's cryptography fails to protect data, through weak algorithms, short keys, incorrect implementation, poor key management, or home-grown schemes.
- The danger is hidden: the app looks like it protects data while the actual confidentiality or integrity is compromised, and other protections that rest on cryptography are undermined too.
- Address it with current strong standard algorithms and adequate key lengths, correct implementation using vetted platform libraries, proper key management in secure storage, and no custom cryptography.
- A pre-submission scan such as PTKD.com surfaces weak cryptographic usage and hardcoded keys, the insufficient-cryptography signals visible in the build.
