OWASP Mobile & IoT Top 10 Complete Guide: 2024 Mobile and IoT Security Vulnerabilities Analysis [2026 Update]
![OWASP Mobile & IoT Top 10 Complete Guide: 2024 Mobile and IoT Security Vulnerabilities Analysis [2026 Update]](/images/blog/owasp/owasp-mobile-iot-hero.webp)
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 2024 | Description |
|---|---|
| New M1: Improper Credential Usage | Emphasizes authentication methods and protection of user identities |
| New M2: Supply Chain Security | Covers risks across the entire lifecycle, from development to release |
| Privacy controls become a separate category | Reflects regulatory requirements such as GDPR and CCPA |
| Greater focus on binary protection | Prevents 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:
- Store credentials securely with Keychain (iOS) / Keystore (Android)
- Implement OAuth 2.0 + PKCE for authentication
- Have the server provide credentials dynamically instead of hardcoding them
- Implement credential expiration and refresh
- 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:
- Maintain a complete SBOM (Software Bill of Materials)
- Regularly scan dependencies for known vulnerabilities (Dependabot, Snyk)
- Verify the integrity and origin of third-party libraries
- Implement a secure CI/CD process
- 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:
- Run all authentication logic on the server side
- Implement strong password policies and account lockout
- Support multi-factor authentication (MFA)
- Use secure session management
- 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:
- Validate and sanitize all user input
- Use parameterized queries to prevent injection
- Encode output data appropriately
- 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:
- Enforce HTTPS (TLS 1.3)
- Implement Certificate Pinning
- Verify the validity of server certificates
- 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:
- Apply the data minimization principle
- Provide a clear privacy policy
- Support user data export and deletion
- Obtain explicit user consent
- 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:
- Obfuscate code with ProGuard/R8 (Android) or similar tools
- Detect Root/Jailbreak environments
- Implement anti-debugging and anti-emulator detection
- 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:
- Establish secure default settings
- Automate security configuration checks
- Remove unnecessary features and services
- 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):
| Level | Name | Applicable Scenarios |
|---|---|---|
| MAS-L1 | Essential Security | General Apps |
| MAS-L2 | Advanced Security | Apps handling sensitive data |
| MAS-R | Resilient Security | Apps needing reverse engineering protection |
| MAS-P | Baseline Privacy | Apps 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:
- Force password change on first use
- Each device uses unique default password
- Prohibit weak passwords
- 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:
- Disable unnecessary services
- Regular updates to patch vulnerabilities
- Network services require authentication
- 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:
- Apply OWASP Top 10 and API Top 10 standards
- All interfaces require authentication and authorization
- 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:
- Updates must use encrypted transmission (HTTPS)
- Firmware must be digitally signed
- Verify firmware integrity
- Prevent version downgrade
- 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:
- Establish BOM (Bill of Materials) list
- Monitor component vulnerability announcements
- Regular component updates
- 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:
- Data minimization principle
- Encrypt sensitive data
- Transparent privacy policy
- 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:
- Use TLS to encrypt all transmission
- Encrypt local data
- 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:
- Device inventory management
- Remote configuration and updates
- Security monitoring and alerting
- 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:
- Secure defaults principle
- Disable unnecessary features
- Mandatory configuration flow
- 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:
- Remove or disable debug interfaces
- Tamper detection
- Encrypted storage
- Implement Secure Boot
IoT Security Testing Methods
IoT security testing requires multi-layer assessment.
Testing Scope:
| Layer | Testing Focus |
|---|---|
| Hardware | Physical interfaces, debug ports, storage media |
| Firmware | Update mechanism, encryption, hardcoded passwords |
| Network | Open services, encryption, authentication |
| Web/App | Standard Web/Mobile security testing |
| API | Authentication, authorization, input validation |
| Cloud | Data security, access control |
Common Tools:
| Tool | Purpose |
|---|---|
| Binwalk | Firmware analysis and extraction |
| Firmwalker | Firmware security scanning |
| Nmap | Network service scanning |
| Wireshark | Network traffic analysis |
| Bus Pirate | Hardware interface analysis |
| OWASP ZAP | Web/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:
- Only download apps from official stores
- Check if app's requested permissions are reasonable
- Review user ratings and reviews
- Confirm developer information
- Pay attention to app's privacy policy
What Development Teams Should Do:
- Use MobSF for automated scanning
- Follow OWASP MASVS checklist
- Conduct code review
- Commission professional penetration testing
- 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:
- Privacy Risk: Cameras, microphones can be hacked
- Springboard: Attackers can enter home network through IoT devices
- Botnet: Used to launch DDoS attacks
- 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:
- Research brand's security record before purchase
- Change default passwords
- Regularly update firmware
- Put IoT devices in separate network segment
- Disable unnecessary remote access features
- 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 ConsultationRelated Articles
What is OWASP? 2026 Complete Guide: Top 10, ZAP Tools, Security Standards Explained
Deep dive into OWASP web security standards, covering Top 10 vulnerability lists, ZAP scanning tools, API/LLM/Mobile security guides. Free resources and enterprise adoption practices.
OWASPOWASP API Security Top 10 Complete Guide: 2023 API Security Vulnerabilities and Protection [2026 Update]
In-depth analysis of OWASP API Top 10 security vulnerabilities, covering BOLA, authentication failures, and all ten API risks, plus protection measures and testing methods. Includes 2021-2024 attack cases.
OWASPOWASP Top 10 Complete Analysis: 2025 Latest Top 10 Web Security Risks (2021 vs 2025 Changes)
In-depth analysis of the OWASP Top 10:2025 web security vulnerability list, mapped item-by-item against the official latest ranking, with a full 2021 vs 2025 comparison (new Software Supply Chain Failures and Mishandling of Exceptional Conditions, SSRF folded into Broken Access Control), explanations and a practical application guide.