The 10 most common security flaws in mobile applications

Key takeaway - According to OWASP Mobile Top 10 2024, 85% of mobile applications have at least one critical vulnerability, exposing businesses to data leaks, GDPR penalties of up to 4% of global revenue, and an average breach cost of $4.45 million according to IBM Security.

Introduction: Mobile Security, a Critical Issue in 2026

Mobile applications have become the primary digital entry point for billions of users. Banking, healthcare, e-commerce, messaging: we entrust our most sensitive data to our smartphones. Yet, according to the OWASP Mobile Top 10 2024 report, 85% of mobile applications have at least one critical vulnerability.

For businesses, the consequences of a security breach are devastating: customer data leaks, GDPR penalties (up to 4% of global revenue), reputation damage, and even legal liability. In 2023, the average cost of a data breach reached $4.45 million according to IBM Security.

This guide details the 10 most common security flaws in mobile development, with concrete examples and solutions to avoid them.

The 10 Most Common Mobile Security Flaws

1. Insecure Data Storage

The problem: Developers store sensitive information (tokens, passwords, personal data) in plain text on the device, accessible to any malicious application or in case of phone theft.

Examples of bad practices:

• Storing JWT tokens in SharedPreferences (Android) or UserDefaults (iOS) without encryption
• Saving passwords in plain text in a local SQLite database
• Logging sensitive information in debug files

Solutions:

• Use Keychain (iOS) or EncryptedSharedPreferences (Android)
• Encrypt local databases with SQLCipher
• Implement a data-at-rest encryption policy
• Never log sensitive information, even in development

// ❌ Bad: plain text storage
localStorage.setItem('authToken', token);

// ✅ Good: use secure storage (React Native)
import * as SecureStore from 'expo-secure-store';
await SecureStore.setItemAsync('authToken', token);

2. Insecure Network Communication

The problem: Data travels in plain text between the application and server, enabling Man-in-the-Middle (MITM) attacks where an attacker intercepts and modifies communications.

Common vulnerabilities:

• Using HTTP instead of HTTPS
• Accepting all SSL certificates (disabling validation)
• Lack of certificate pinning
• Transmitting sensitive data in URLs (query strings)

Solutions:

• Enforce HTTPS for all communications
• Implement certificate pinning to verify server identity
• Use TLS 1.3 minimum
• Transmit sensitive data only in POST request bodies

// Certificate pinning configuration (React Native)
const sslPinning = {
  certs: ['sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='],
  disableAllSecurityOptions: false,
};

3. Weak Authentication and Session Management

The problem: Weak authentication mechanisms allow attackers to take over user accounts or maintain active sessions indefinitely.

Common flaws:

• Session tokens that never expire
• No server-side verification (blind trust in the client)
• No protection against brute force attacks
• Token reuse after logout
• Storing passwords client-side for "auto-login"

Solutions:

• Implement JWT tokens with short expiration (15-30 min) + refresh tokens
• Invalidate sessions server-side on logout
• Use biometric authentication (Face ID, Touch ID) as a second factor
• Implement rate limiting on authentication endpoints
• Never store passwords, only revocable tokens

4. Code Injection and Unvalidated Inputs

The problem: The application accepts user input without validation, allowing injection of malicious code (SQL, JavaScript, system commands).

Types of injection:

• SQL Injection: manipulation of database queries
• XSS (Cross-Site Scripting): JavaScript injection in WebViews
• Command Injection: execution of system commands
• Path Traversal: access to unauthorized files

Solutions:

• Validate and sanitize all user inputs (client AND server)
• Use prepared statements (parameterized queries)
• Encode outputs before displaying in WebViews
• Implement a whitelist of allowed characters

// ❌ Bad: direct concatenation
const query = `SELECT * FROM users WHERE email = '${userInput}'`;

// ✅ Good: prepared statement
const query = 'SELECT * FROM users WHERE email = ?';
db.execute(query, [userInput]);

5. Using Vulnerable Components

The problem: Applications use third-party libraries (npm, CocoaPods, Gradle) containing known vulnerabilities that are never updated.

Risks:

• 70% of applications contain at least one vulnerable dependency
• Attackers specifically target published CVEs (Common Vulnerabilities and Exposures)
• A single compromised dependency can affect thousands of applications

Solutions:

• Regularly audit dependencies (npm audit, yarn audit)
• Use tools like Snyk, Dependabot, or OWASP Dependency-Check
• Establish a dependency update policy
• Prefer actively maintained libraries with an active community
• Implement an SBOM (Software Bill of Materials) to track components

# npm dependency audit
npm audit

# Automatic vulnerability fixes
npm audit fix

6. Lack of Source Code Protection

The problem: Application code is easily decompilable, exposing business logic, API keys, and proprietary algorithms.

What an attacker can extract:

• Hardcoded API keys and secrets
• Custom encryption algorithms
• Client-side validation logic
• Undocumented API endpoints
• Anti-cheat mechanisms (games)

Solutions:

• Code obfuscation (ProGuard/R8 for Android, SwiftShield for iOS)
• Never hardcode secrets in code
• Use environment variables and secret management services
• Implement root/jailbreak detection
• Use native code for sensitive operations

// ❌ Bad: hardcoded secret
const API_KEY = 'sk_live_abc123xyz';

// ✅ Good: environment variable
const API_KEY = process.env.API_KEY;

// ✅ Even better: secure retrieval from backend
const apiKey = await fetchApiKeyFromSecureBackend();

7. Improper Permission Management

The problem: The application requests excessive permissions or doesn't properly handle permission denials, creating data leak risks or poor user experience.

Bad practices:

• Requesting all permissions at first launch
• Accessing data without checking if permission is granted
• Not explaining why a permission is needed
• Continuing to operate with sensitive permissions in the background

Solutions:

• Apply the principle of least privilege: only request necessary permissions
• Request permissions when they're needed (lazy permissions)
• Clearly explain the use of each permission
• Gracefully handle permission denials
• Regularly audit permissions used

8. Flaws in Inter-Application Communication

The problem: Communication mechanisms between applications (Deep Links, Intents, URL Schemes) can be exploited to steal data or trigger unauthorized actions.

Attack vectors:

• Unvalidated Deep Links: redirection to malicious sites
• Intent hijacking (Android): interception of inter-app communications
• URL Scheme collision: a malicious app registers on the same scheme
• Clipboard snooping: clipboard reading by third-party apps

Solutions:

• Strictly validate all data received via Deep Links
• Use App Links (Android) and Universal Links (iOS) with domain verification
• Implement signing for sensitive communications
• Avoid passing sensitive data via clipboard
• Use explicit Intents rather than implicit ones (Android)

// Deep Link validation
const validateDeepLink = (url: string): boolean => {
  const allowedHosts = ['app.example.com', 'www.example.com'];
  const parsedUrl = new URL(url);
  return allowedHosts.includes(parsedUrl.host);
};

9. Lack of Compromised Environment Detection

The problem: The application runs without checking if the environment is secure, allowing attacks from rooted/jailbroken devices, emulators, or modified app versions.

Risks:

• Rooted/jailbroken devices: complete access to the file system
• Emulators: facilitates reverse engineering and attack automation
• Hooking frameworks (Frida, Xposed): runtime modification of app behavior
• Repackaged apps: modified versions with malicious code

Solutions:

• Implement root/jailbreak detection
• Detect emulators and debug environments
• Verify application integrity (signature)
• Use solutions like Google Play Integrity API or Apple DeviceCheck
• Adapt behavior based on risk level (block or limit features)

10. Poor Cryptography Implementation

The problem: Incorrect use of encryption algorithms, making data protection ineffective even when implemented.

Common mistakes:

• Using obsolete algorithms (MD5, SHA1, DES)
• Hardcoding encryption keys in code
• Using predictable initialization vectors (IV)
• Implementing your own encryption algorithm
• Storing keys in the same location as encrypted data

Solutions:

• Use modern, proven algorithms (AES-256-GCM, ChaCha20)
• Generate keys with a secure cryptographic generator
• Use unique and random IVs for each operation
• Store keys in the device's Keychain/Keystore
• Use proven libraries (libsodium, CryptoKit)

// ❌ Bad: MD5 and hardcoded key
const hash = md5(password);
const encrypted = encrypt(data, 'mySecretKey123');

// ✅ Good: modern algorithms and secure key management
import { randomBytes, createCipheriv } from 'crypto';

const key = await getKeyFromSecureStorage(); // Key stored in Keychain
const iv = randomBytes(16); // Random IV
const cipher = createCipheriv('aes-256-gcm', key, iv);

Security Checklist for Your Mobile Applications

Use this checklist to audit your applications:

Storage and Data

• No sensitive data stored in plain text on device
• Keychain/Keystore used for secrets
• No logs containing sensitive information
• Local databases encrypted

Network

• HTTPS mandatory for all communications
• Certificate pinning implemented
• TLS 1.2+ minimum
• No sensitive data in URLs

Authentication

• Tokens with short expiration
• Server-side session invalidation
• Brute force protection
• Biometric authentication support

Code

• Code obfuscation enabled
• No hardcoded secrets
• Dependencies regularly audited
• Root/jailbreak detection implemented

User Input

• Client AND server-side validation
• Prepared statements for database queries
• Output encoding in WebViews

FAQ

Is my application really at risk?

Yes. According to Verizon, 43% of cyberattacks target small and medium businesses. Attackers use automated tools that scan thousands of applications looking for known vulnerabilities. Your company's size is not protection.

How much does a mobile security audit cost?

A professional security audit typically costs between €3,000 and €15,000 depending on application complexity. It's a minimal investment compared to the average cost of a data breach ($4.45M) or GDPR penalties.

Are cross-platform frameworks (React Native, Flutter) less secure?

Not inherently. Modern frameworks like React Native and Flutter offer good default security. Vulnerabilities mainly come from poor development practices, not the framework itself. The same security principles apply.

Where should I start to secure my existing application?

1. Audit your dependencies (npm audit) - it's free and fast
2. Check local storage - look for sensitive data in plain text
3. Test with a proxy (Charles, Burp) - verify network communications
4. Consult an expert for a thorough audit

Conclusion: Security Is Not Optional

Mobile application security is no longer a "nice-to-have" but a legal and business obligation. GDPR, the NIS2 directive, and user expectations require a high level of protection.

The 10 flaws presented in this article cover 90% of vulnerabilities found in audits. By addressing them methodically, you drastically reduce your attack surface.

Investing in security is always cheaper than the consequences of a breach.

Neodigit: Secure Mobile Applications by Design

At Neodigit, security is integrated from the design phase of your mobile applications, not added as an afterthought.

Our approach:

• Security by design: secure architecture from the first lines of code
• Modern stack: React Native with security best practices
• Continuous auditing: automated analysis of dependencies and code
• Penetration testing: validation by experts before each release
• GDPR compliance: personal data protection built-in

Do you have an existing application to audit or a new project to secure? Let's talk and together we'll build an application your users can trust with confidence.