Back to HomeOWASP

OWASP Mobile & IoT Top 10 Complete Guide: 2024 Mobile and IoT Security Vulnerabilities Analysis [2026 Update]

16 min min read
#OWASP#Mobile Security#IoT Security#MASVS#App Security

OWASP Mobile & IoT Top 10 Complete Guide: 2024 Mobile and IoT Security Vulnerabilities Analysis [2026 Update]

Version Note: This article covers OWASP Mobile Top 10 2024 version (officially released in 2024) and IoT Top 10. The 2024 version has significant changes compared to 2016, adding modern topics like supply chain security and credential management.


Part 1: OWASP Mobile Top 10

What is OWASP Mobile Top 10?

OWASP Mobile Top 10 is the list of ten major security risks for mobile applications. It covers common vulnerability types on iOS and Android platforms.

Mobile app security challenges differ from web applications:

  • Code executes on user devices
  • Can be reverse-engineered and analyzed
  • Must handle device-specific security mechanisms
  • Network environment is uncontrollable (public WiFi)

The 2024 version is the first major update since 2016, reflecting how mobile security has evolved over the past 8 years:

Major Changes in 2024Description
New M1: Improper Credential UsageEmphasizes authentication methods and protection of user identities
New M2: Supply Chain SecurityCovers risks across the entire lifecycle, from development to release
Privacy controls become a separate categoryReflects regulatory requirements such as GDPR and CCPA
Greater focus on binary protectionPrevents reverse engineering and code tampering

To learn about the OWASP organization and web security standards, refer to the OWASP Complete Guide.


Mobile Top 10 Vulnerability Analysis (2024 Version)

Below is the complete OWASP Mobile Top 10 2024 list, which changes significantly from the 2016 version.


M1: Improper Credential Usage 🆕

Description: The app has flaws in how it handles user credentials, including insecure storage, transmission, or verification.

New in 2024: Reflects a greater emphasis on authentication methods and protection of user identities.

Common Issues:

  • Hardcoding API keys or passwords in code
  • Storing credentials in insecure locations
  • Credentials not encrypted in transit
  • Lack of proper credential rotation
  • Incorrectly implemented biometric authentication

Attack Scenario:

Developer hardcodes an API key in the app
Attacker decompiles the APK/IPA file
With the key, the attacker can impersonate the app and access backend services

Protection Measures:

  1. Store credentials securely with Keychain (iOS) / Keystore (Android)
  2. Implement OAuth 2.0 + PKCE for authentication
  3. Have the server provide credentials dynamically instead of hardcoding them
  4. Implement credential expiration and refresh
  5. Protect sensitive data with hardware security modules (such as Secure Enclave)

M2: Inadequate Supply Chain Security 🆕

Description: Third-party libraries, SDKs, or development tools used by the app carry security risks.

New in 2024: Reflects a focus on security across the entire development lifecycle.

Risk Sources:

  • Third-party SDKs with known vulnerabilities
  • npm/Maven/CocoaPods packages injected with malicious code
  • Insecure CI/CD pipelines
  • Unverified code signatures
  • Indirect impact when a vendor is compromised

Attack Scenario:

App uses a popular image-processing SDK
The SDK is compromised and a backdoor is planted
Every app using the SDK is affected

Protection Measures:

  1. Maintain a complete SBOM (Software Bill of Materials)
  2. Regularly scan dependencies for known vulnerabilities (Dependabot, Snyk)
  3. Verify the integrity and origin of third-party libraries
  4. Implement a secure CI/CD process
  5. Monitor vendors' security advisories

M3: Insecure Authentication/Authorization

Description: The app's authentication or access control mechanisms have vulnerabilities.

Common Issues:

  • Authenticating only on the client side
  • Weak password policies
  • No multi-factor authentication
  • Improper Session Token management
  • Authorization checks that can be bypassed

Protection Measures:

  1. Run all authentication logic on the server side
  2. Implement strong password policies and account lockout
  3. Support multi-factor authentication (MFA)
  4. Use secure session management
  5. Implement a complete authorization matrix

M4: Insufficient Input/Output Validation

Description: The app does not properly validate user input or system output, which can lead to injection attacks or data leaks.

Common Issues:

  • SQL Injection
  • Cross-site scripting (XSS)
  • Path Traversal
  • XML/JSON injection
  • Format string vulnerabilities

Protection Measures:

  1. Validate and sanitize all user input
  2. Use parameterized queries to prevent injection
  3. Encode output data appropriately
  4. Use allowlist validation instead of denylists

M5: Insecure Communication

Description: Communication between the app and the server lacks proper protection.

Common Issues:

  • Using HTTP instead of HTTPS
  • Accepting invalid or self-signed certificates
  • Not implementing Certificate Pinning
  • Using outdated TLS versions
  • Sensitive data not encrypted in transit

Protection Measures:

  1. Enforce HTTPS (TLS 1.3)
  2. Implement Certificate Pinning
  3. Verify the validity of server certificates
  4. Use App Transport Security (iOS) / Network Security Config (Android)

M6: Inadequate Privacy Controls

Description: The way the app collects, processes, or stores personal data does not meet privacy requirements.

Common Issues:

  • Collecting more personal data than necessary
  • Not informing users about data collection
  • No option to delete data
  • Sharing data with third parties without consent
  • Violating regulations such as GDPR and CCPA

Protection Measures:

  1. Apply the data minimization principle
  2. Provide a clear privacy policy
  3. Support user data export and deletion
  4. Obtain explicit user consent
  5. Ensure compliance with local privacy laws

M7: Insufficient Binary Protections

Description: The app's binary lacks protection and is easy to reverse-engineer or tamper with.

Common Issues:

  • No code obfuscation
  • No Root/Jailbreak detection
  • No anti-debugging mechanisms
  • No integrity checks
  • Sensitive strings not encrypted

Protection Measures:

  1. Obfuscate code with ProGuard/R8 (Android) or similar tools
  2. Detect Root/Jailbreak environments
  3. Implement anti-debugging and anti-emulator detection
  4. Use code signing and integrity verification

M8: Security Misconfiguration

Description: Security settings of the app or backend services are misconfigured.

Common Issues:

  • Debug mode enabled in production builds
  • Default credentials not changed
  • Error messages exposing sensitive information
  • Unnecessary services or ports open
  • Overly permissive permission settings

Protection Measures:

  1. Establish secure default settings
  2. Automate security configuration checks
  3. Remove unnecessary features and services
  4. Review security settings regularly

M9: Insecure Data Storage

Description: Sensitive data stored insecurely on the device.

Risk Locations:

  • SharedPreferences / NSUserDefaults (plaintext storage)
  • SQLite database (unencrypted)
  • Local file system
  • System logs
  • Clipboard
  • Backup files

Attack Methods:

  • Malicious app reading shared storage
  • Device lost or stolen
  • Obtaining data through backup files
  • Accessing app sandbox after Root/Jailbreak

Protection Measures:

// iOS - Use Keychain for sensitive data storage
let query: [String: Any] = [
    kSecClass as String: kSecClassGenericPassword,
    kSecAttrAccount as String: "userToken",
    kSecValueData as String: tokenData,
    kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlocked
]
SecItemAdd(query as CFDictionary, nil)
// Android - Use EncryptedSharedPreferences
val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val sharedPreferences = EncryptedSharedPreferences.create(
    context,
    "secret_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

M10: Insufficient Cryptography

Description: Using insecure encryption methods or flawed encryption implementation.

Common Issues:

  • Using known insecure algorithms (MD5, SHA1, DES)
  • Keys hardcoded in source code
  • Self-implemented encryption algorithms
  • Improper key management

Bad Example:

// Wrong: Key hardcoded in code
private static final String SECRET_KEY = "MySecretKey123";

// Wrong: Using insecure algorithm
MessageDigest md = MessageDigest.getInstance("MD5");

Correct Approach:

// Use Android Keystore to generate and store keys
KeyGenerator keyGenerator = KeyGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");
keyGenerator.init(
    new KeyGenParameterSpec.Builder("MyKey",
        KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
        .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
        .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
        .build());
SecretKey key = keyGenerator.generateKey();

OWASP MASVS and MASTG

Besides Mobile Top 10, OWASP provides a more complete Mobile security framework.

MASVS (Mobile Application Security Verification Standard)

MASVS is the mobile app security verification standard defining security requirements apps should meet.

MAS Profiles (formerly the L1/L2/R verification levels):

LevelNameApplicable Scenarios
MAS-L1Essential SecurityGeneral Apps
MAS-L2Advanced SecurityApps handling sensitive data
MAS-RResilient SecurityApps needing reverse engineering protection
MAS-PBaseline PrivacyApps needing privacy protection

MASVS Control Categories:

  • MASVS-STORAGE: Data Storage
  • MASVS-CRYPTO: Cryptography
  • MASVS-AUTH: Authentication & Authorization
  • MASVS-NETWORK: Network Communication
  • MASVS-PLATFORM: Platform Interaction
  • MASVS-CODE: Code Quality
  • MASVS-RESILIENCE: Anti-Reverse Engineering
  • MASVS-PRIVACY: Privacy

MASTG (Mobile Application Security Testing Guide)

MASTG is the implementation guide for MASVS. It details how to test each control.

Contents Include:

  • iOS/Android platform security mechanism explanations
  • Testing methods for each control
  • Testing tool usage tutorials
  • Test case examples

These two documents are essential references for Mobile App security assessment.


Mobile App Security Testing Tools

MobSF (Mobile Security Framework)

Open-source automated mobile app security testing framework.

Features:

  • Static analysis (no app execution needed)
  • Dynamic analysis (runtime testing)
  • Supports Android APK, iOS IPA, source code
  • Automatic report generation

Usage:

# Docker installation
docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf

# Open browser
# http://localhost:8000
# Upload APK/IPA to analyze

QARK (Quick Android Review Kit)

LinkedIn open-source Android app static analysis tool.

Features:

  • Focuses on finding security vulnerabilities
  • Can analyze APK or source code
  • Generates detailed vulnerability reports
# Install
pip install qark

# Analyze APK
qark --apk path/to/app.apk

# Analyze source code
qark --java path/to/source/

Frida

Powerful dynamic analysis framework. Can hook and modify app behavior in real-time.

Uses:

  • Bypass SSL Pinning
  • Analyze encryption logic
  • Modify function return values
  • Trace function calls
// Frida Script - Bypass Root detection
Java.perform(function() {
    var RootCheck = Java.use("com.app.security.RootCheck");
    RootCheck.isRooted.implementation = function() {
        console.log("Root check bypassed");
        return false;
    };
});

Combined with OWASP ZAP, you can perform more complete testing of app APIs.


Part 2: OWASP IoT Top 10

What is OWASP IoT Top 10?

OWASP IoT Top 10 is the list of ten major security risks for IoT devices.

IoT device security challenges:

  • Limited computational resources, difficult to implement complete security mechanisms
  • Imperfect update mechanisms
  • Insecure default configurations
  • Complex supply chains
  • Long lifecycle (may operate for over ten years)

The 2018 version is the current latest. It covers the complete IoT ecosystem from hardware to cloud.


IoT Top 10 Vulnerability Analysis

I1: Weak, Guessable, or Hardcoded Passwords

Issues:

  • Using default passwords like admin/admin, root/root
  • Passwords hardcoded in firmware
  • Not forcing users to change default passwords
  • Weak password policies

Real Case: 2016 Mirai botnet attack. Exploited IoT device default passwords, infected hundreds of thousands of devices, launched the largest DDoS attack in history.

Protection Measures:

  1. Force password change on first use
  2. Each device uses unique default password
  3. Prohibit weak passwords
  4. Support multi-factor authentication

I2: Insecure Network Services

Issues:

  • Unnecessary network services enabled
  • Services with known unpatched vulnerabilities
  • Accessible without authentication
  • Exposed management interfaces

Common Problem Services:

  • Telnet (plaintext transmission)
  • SSH without password
  • Public management web interface
  • UPnP (auto-opens ports)

Protection Measures:

  1. Disable unnecessary services
  2. Regular updates to patch vulnerabilities
  3. Network services require authentication
  4. Use firewall to limit access

I3: Insecure Ecosystem Interfaces

Issues: IoT devices typically connect to mobile apps, cloud platforms, APIs, etc. Security issues in these interfaces affect the entire system.

Common Issues:

  • Web management interface has XSS, SQL Injection
  • API lacks authentication or has weak authentication
  • Mobile app stores sensitive data insecurely

Protection Measures:

  1. Apply OWASP Top 10 and API Top 10 standards
  2. All interfaces require authentication and authorization
  3. Input validation and output encoding

I4: Lack of Secure Update Mechanism

Issues:

  • No firmware update capability
  • Updates not encrypted during transmission
  • Update files not signed
  • No downgrade attack prevention

Attack Scenario:

Attacker intercepts firmware update traffic
Injects malicious code
Device downloads and installs malicious firmware
Device becomes part of botnet

Protection Measures:

  1. Updates must use encrypted transmission (HTTPS)
  2. Firmware must be digitally signed
  3. Verify firmware integrity
  4. Prevent version downgrade
  5. Support automatic updates

I5: Use of Insecure or Outdated Components

Issues:

  • Using libraries with known vulnerabilities
  • Outdated operating system versions
  • Not updating third-party components

Protection Measures:

  1. Establish BOM (Bill of Materials) list
  2. Monitor component vulnerability announcements
  3. Regular component updates
  4. Retire unmaintained components

I6: Insufficient Privacy Protection

Issues:

  • Collecting excessive user data
  • Data storage and transmission not encrypted
  • Not informing users of data usage
  • Data retained too long

Protection Measures:

  1. Data minimization principle
  2. Encrypt sensitive data
  3. Transparent privacy policy
  4. Provide data deletion option

I7: Insecure Data Transfer and Storage

Issues:

  • Sensitive data transmitted in plaintext
  • Local storage not encrypted
  • Improper key management

Protection Measures:

  1. Use TLS to encrypt all transmission
  2. Encrypt local data
  3. Secure key storage

I8: Lack of Device Management

Issues:

  • Cannot remotely manage devices
  • Cannot monitor device status
  • Cannot track assets
  • Lacks logging

Enterprise IoT deployment needs:

  1. Device inventory management
  2. Remote configuration and updates
  3. Security monitoring and alerting
  4. Device decommissioning process

I9: Insecure Default Settings

Issues:

  • Unnecessary features enabled by default
  • Default passwords too simple
  • Default permissions too broad
  • Debug mode enabled by default

Protection Measures:

  1. Secure defaults principle
  2. Disable unnecessary features
  3. Mandatory configuration flow
  4. Provide secure configuration guide

I10: Lack of Physical Hardening

Issues:

  • Exposed debug interfaces (UART, JTAG)
  • No tamper detection
  • Firmware easily readable
  • No Secure Boot

Protection Measures:

  1. Remove or disable debug interfaces
  2. Tamper detection
  3. Encrypted storage
  4. Implement Secure Boot

IoT Security Testing Methods

IoT security testing requires multi-layer assessment.

Testing Scope:

LayerTesting Focus
HardwarePhysical interfaces, debug ports, storage media
FirmwareUpdate mechanism, encryption, hardcoded passwords
NetworkOpen services, encryption, authentication
Web/AppStandard Web/Mobile security testing
APIAuthentication, authorization, input validation
CloudData security, access control

Common Tools:

ToolPurpose
BinwalkFirmware analysis and extraction
FirmwalkerFirmware security scanning
NmapNetwork service scanning
WiresharkNetwork traffic analysis
Bus PirateHardware interface analysis
OWASP ZAPWeb/API scanning

Firmware Analysis Example:

# Use Binwalk to extract firmware
binwalk -e firmware.bin

# Search for hardcoded passwords
grep -r "password" _firmware.bin.extracted/
grep -r "secret" _firmware.bin.extracted/

# Find SSH keys
find _firmware.bin.extracted/ -name "*.pem"
find _firmware.bin.extracted/ -name "id_rsa"

FAQ

Q1: Is iOS or Android More Secure?

Both have pros and cons, no absolute answer.

iOS Security Advantages:

  • Closed ecosystem, strict app review
  • High system update coverage
  • Hardware and software integrated security mechanisms
  • Stricter sandbox isolation

Android Security Advantages:

  • Open source, security mechanisms can be reviewed
  • More granular permission control
  • Rich enterprise management features
  • Can install security apps (antivirus, VPN)

Actual Risk Comparison:

  • iOS devices less targeted by malware
  • Android has more malware (due to market share, sideloading)
  • Both have been targeted by nation-state attacks
  • App's own security matters more than platform

Conclusion: Choosing either platform, keeping system updated, only installing trusted apps, and being careful with permissions matters more than which platform you choose.

Q2: How to Check if an App is Secure?

What Regular Users Can Do:

  1. Only download apps from official stores
  2. Check if app's requested permissions are reasonable
  3. Review user ratings and reviews
  4. Confirm developer information
  5. Pay attention to app's privacy policy

What Development Teams Should Do:

  1. Use MobSF for automated scanning
  2. Follow OWASP MASVS checklist
  3. Conduct code review
  4. Commission professional penetration testing
  5. Regular reassessment

App Security Check Indicators:

  • Is communication encrypted (check if HTTPS is used)
  • Is Certificate Pinning implemented
  • Is local data encrypted
  • Is authentication mechanism secure
  • Are there anti-reverse engineering measures

Q3: Should I Worry About Smart Home Device Security?

Yes, and it's very important.

Smart Home Device Security Risks:

  1. Privacy Risk: Cameras, microphones can be hacked
  2. Springboard: Attackers can enter home network through IoT devices
  3. Botnet: Used to launch DDoS attacks
  4. Ransomware: Smart locks being hacked could lock you out

Real Cases:

  • Smart cameras hacked to livestream home footage
  • Smart speakers used for eavesdropping
  • Smart TVs infected with adware
  • Baby monitors accessed by strangers

Protection Recommendations:

  1. Research brand's security record before purchase
  2. Change default passwords
  3. Regularly update firmware
  4. Put IoT devices in separate network segment
  5. Disable unnecessary remote access features
  6. Factory reset devices when no longer used

Conclusion

Mobile and IoT device security challenges differ from traditional web applications and require specialized security thinking.

Mobile Security Key Points:

  • Data storage must be encrypted
  • Communication needs Certificate Pinning
  • Authentication and authorization verified server-side
  • Prevent reverse engineering and code tampering
  • Follow MASVS standards

IoT Security Key Points:

  • Eliminate default passwords
  • Establish secure update mechanism
  • Minimize attack surface
  • Consider entire ecosystem
  • Don't neglect physical security

Next step recommendations:

  • Check your app security level with MASVS
  • Inventory IoT devices in your environment
  • Confirm all device firmware is latest version
  • Plan IoT device network isolation

If you're developing AI-powered Mobile or IoT applications, also note the OWASP LLM Top 10 risks. For hands-on practice, Juice Shop is a great starting point.

Need Professional Cloud Advice?

Whether you're evaluating cloud platforms, optimizing existing architecture, or looking for cost-saving solutions, we can help

Book Free Consultation

Related Articles