The State of Mobile App Security, 2026

Key Takeaways:

• Quokka’s data shows that mobile app vulnerabilities are widespread
• Known issues like weak cryptography still dominate app risk
• Third-party dependencies drive hidden, high-severity exposure

Mobile apps have quietly become one of the largest and least understood attack surfaces in the enterprise. TQuokka performed an analysis of more than 150,000 mobile applications throughout 2025. Now, we’re taking a look back at those scans to better understand the security risks present across today’s mobile ecosystem. The results show that foundational security weaknesses remain widespread across both Android and iOS apps, often exposing sensitive data, weakening encryption protections, or creating exploitable attack paths.

This report breaks down those findings by category, explains what each vulnerability means in practice, and identifies the patterns that explain why so many problems persist year over year. The goal is not to catalog failure but to make the risks concrete enough to act on.

The Unencrypted Web Problem

Finding: HTTP URLs found in 94.3% of Android apps and 61.7% of iOS apps

Unencrypted HTTP traffic is the most pervasive security issue in mobile apps today. When an app communicates over HTTP instead of HTTPS, all data in transit — usernames, passwords, session tokens, API responses — is transmitted in plaintext. Any attacker on the same network can read it, copy it, or modify it without detection.

This is not a theoretical risk. On public Wi-Fi networks, man-in-the-middle (MITM) attacks require minimal technical skill and are documented in the wild. An attacker intercepts the connection between the device and the server, captures credentials or session data, and the user never knows. The app appears to function normally.

The fix: Enforce HTTPS for all network communication, with no exceptions. For sensitive endpoints, implement certificate pinning to prevent interception via fraudulent certificates.

SQL Injection isn’t Dead

Finding: Vulnerable to SQL injection — 87.9% of Android apps, 63.7% of iOS apps

Despite being on the OWASP Top 10 list of critical vulnerabilities for over two decades, SQL injection vulnerabilities are still rampant. SQL injection occurs when an application constructs database queries by directly concatenating user input rather than using parameterized queries or prepared statements. An attacker can manipulate the input to alter the query’s logic, extracting data they should not access, bypassing authentication, modifying records, or in some configurations, executing commands on the underlying server.

Mobile apps are not immune because they are apps rather than websites. Any interface that passes user input to a database query is a potential injection point, and mobile apps interact with backend databases constantly. 

The fix: Use parameterized queries, which adds negligible development overhead.

Cryptographic Misconfiguration Across the Mobile Ecosystem

Finding: ECB mode cipher: 68.1% Android / 24% iOS

ECB (Electronic Codebook) mode is a cipher configuration that has been considered cryptographically broken for decades. The flaw is fundamental: ECB encrypts each block of plaintext independently, which means identical input blocks always produce identical output blocks. This allows an attacker to detect patterns in encrypted data without ever decrypting it, leaking information about the plaintext from the ciphertext alone. ECB mode is explicitly prohibited in every modern cryptographic guidance document. Its presence in 68.1% of Android apps reflects a persistent gap in developer education about cipher mode selection.

The fix: Replace ECB with AES in GCM or CBC mode; both are natively supported on Android and iOS and eliminate the pattern-leakage vulnerability entirely.

Finding: Hardcoded cryptographic keys: 47.8% Android / 17.6% iOS

A hardcoded cryptographic key is a secret embedded directly in the compiled application binary. Every user who installs the app receives a copy. Decompiling an Android APK to recover embedded strings is a beginner-level task that takes minutes. Any key in a binary is a key that will eventually be extracted. When a hardcoded key is exposed, every user’s data protected by that key is compromised — not just one user, but all users, retroactively. Credentials, tokens, and cryptographic secrets must never live in application code. They belong in secure platform key storage or fetched at runtime from authenticated secrets management services.

The fix: Migrate secrets to Android Keystore or iOS Secure Enclave for on-device keys, or fetch them at runtime from an authenticated secrets management service such as HashiCorp Vault or AWS Secrets Manager.

Finding: Weak symmetric ciphers: 14.5% Android / 6% iOS

Symmetric ciphers protect data at rest and in transit at scale. Not all of them, however, offer equivalent security. Algorithms such as DES and RC4 were once industry-standard but have since been cryptographically broken through advances in computing power and attack techniques. DES, for example, can be brute-forced in hours with commodity hardware, and RC4 carries known statistical biases that allow plaintext recovery under realistic conditions. Any data encrypted with these algorithms should be considered potentially exposed, regardless of key management practices. 

The fix: Replace any use of DES, 3DES, or RC4 with AES-256, which is well-supported across both platforms and the current industry standard for symmetric encryption.

Finding: Insufficient key length: 0.5% Android / 11.3% iOS

This is a rare instance where iOS shows a higher vulnerability rate than Android (11.3% vs. 0.5%). The most likely explanation is a legacy code effect — older iOS apps using cryptographic configurations that predate current key length recommendations. Platform defaults do not retroactively fix code written under older standards, and older apps require their own audit cycles regardless of platform.

The fix: Audit cryptographic configurations across the codebase and enforce a minimum of 2048-bit RSA or 256-bit AES keys, paying particular attention to older modules that may predate current length recommendations.

A Cluster of Additional Cryptographic Misconfigurations

Additional cryptographic findings appear in Quokka’s dataset that do not individually constitute emergencies but collectively degrade an app’s security posture. Each suggests a developer reaching for cryptographic tools without fully understanding their configuration requirements:

• Hardcoded initialization vectors (IVs): A fixed IV means identical inputs always produce identical outputs, leaking information about data patterns over time. IVs exist specifically to introduce randomness — hardcoding them defeats the purpose.
• RSA without OAEP padding: Omitting Optimal Asymmetric Encryption Padding (OAEP) leaves implementations exposed to chosen-ciphertext attacks that OAEP was specifically designed to prevent.
• Password-based encryption with insufficient iteration counts: Low iteration counts in functions like PBKDF2 make brute-force attacks on user passwords meaningfully faster than necessary — a free gift to attackers.
• Weak HMAC configurations: A weakly configured HMAC undermines the integrity guarantee the developer presumably thought they were adding.
• RSA keys below recommended lengths: Shorter RSA keys are not broken today, but they are on a deadline. Rotating to current recommended lengths is a routine maintenance task. Waiting until the keys are actively vulnerable is not a strategy.

None of these require an emergency response, but all of them are worth fixing on the next pass through the codebase — not because they are urgent individually, but because there is no good reason to leave them in place.

Vulnerabilities That Persist Despite Being Well Understood

Two of the most consequential vulnerabilities in mobile applications are also among the most preventable: encryption without integrity verification and hardcoded API keys. Both have been documented for decades. Both have known fixes. Both remain widespread.

When encryption is implemented without integrity verification, an attacker can alter ciphertext in transit. The receiving application decrypts the modified payload, acts on it, and never detects the tampering. This class of attack, known as bit-flipping, is well-documented and has been demonstrated in production systems. It is not theoretical.

We also found that unencrypted sockets appear in 89.1% of Android apps. Raw sockets operate below the HTTP layer. When an app opens an unencrypted socket, it creates a direct, unprotected channel to a remote server — one that can be intercepted and monitored at the network level. In apps that handle authentication, financial data, or health information, this creates a significant attack surface.

Hardcoded API keys are in some ways a more immediate risk. Any key embedded in a compiled binary will eventually be extracted. The consequences depend on what the key unlocks, but the range is severe: silent data exfiltration, fraudulent charges, or full infrastructure takeover. In a recent scan of our full database, we found that 39.5% of apps contain hardcoded Google API keys that could provide access to AI functionality and billable LLM resources. That is one key type among many.

Hardcoded AWS Keys: Small Numbers but Serious Problem

Hardcoded AWS credentials in a mobile binary represent a category-one security incident regardless of how many apps are affected. Unlike widespread-but-minor misconfigurations that represent manageable aggregate risk, a single exposed AWS key can mean catastrophic, immediate consequences, and we found 50+ apps with hardcoded AWS keys.

Depending on the IAM policy attached to the exposed key, an attacker may gain: read access to production databases; write access to storage buckets containing customer data; the ability to create, modify, or destroy infrastructure; access to other credentials stored in AWS Secrets Manager; or a pivot point into adjacent systems and services. In a few extreme cases, these were keys for the root user, which provided full, unfettered access to the entire AWS infrastructure. One app with this problem is one too many. 

SBOM Analysis: Old Vulnerabilities Still Shipping

For each app analysis, we generate a Software Bill of Materials (SBOM) to identify risks in third-party dependencies. Despite there being known vulnerabilities, components with CVEs remain, but less so in iOS apps than Android apps. The chart below shows the percent of apps scanned that contain Critical or High Severity CVEs.

Android apps showed a particularly pronounced pattern of legacy exposure, with Critical CVEs spanning nearly a decade of unpatched vulnerabilities. Some of the most interesting findings include:

• 29 Android apps contained a High severity CVE originally disclosed in 2009
• 1,096 Android apps contained a Critical CVE originally disclosed in 2017
• 445 Android apps contained a Critical CVE originally disclosed in 2018
• 523 Android apps contained a Critical CVE originally disclosed in 2019

iOS apps showed a different but equally concerning pattern, with Critical CVE exposure concentrated in far more recent disclosures:

• 2,075 iOS apps contained a Critical CVE originally disclosed in 2023
• 36 iOS apps contained a Critical CVE originally disclosed in 2024

Across both platforms, unpatched dependencies are a known, measurable, and correctable risk and the evidence shows most organizations are not correcting them.

Why These Vulnerabilities Persist and What Needs to Change

The findings in this analysis are not surprising to security researchers. What is surprising — and concerning — is how little has changed. These are not novel or exotic vulnerabilities. They are well-documented, well-understood, and largely preventable with existing tools and practices.

Several factors likely explain their persistence:

• Security is treated as optional in many development workflows rather than as a baseline requirement
• Legacy code ages without being audited, accumulating risks that were accepted years ago when standards were lower
• Developer education on cryptography is uneven — it is possible to write code that looks secure but fails in the ways our analysis detected
• App store review processes do not catch the majority of the vulnerabilities described here

For meaningful improvement, the responsibility is shared. Developers need to treat app security analysis as a standard part of their build process. Enterprises deploying apps — particularly in regulated industries — need to require security assessments before adoption. Platform owners need to raise the bar for what gets into stores. And users deserve transparency about the security posture of the apps they use daily.

Security Best Practices for the Modern Mobile App Ecosystem

The findings from our analysis show that mobile security risks are not theoretical. They are widespread, measurable, and present in apps that employees and organizations rely on every day. Addressing them requires action on two fronts. Developers need to build security into apps from the beginning, and organizations must take responsibility for understanding and managing the mobile risks within their own environments.

What Developers Should Do to Ensure the Security of the Mobile Apps They Build

Developers play a critical role in reducing risk before applications ever reach users. Many of the issues identified in our analysis are preventable through disciplined security practices during development.

Use modern, secure cryptographic implementations

• Replace deprecated algorithms and cipher modes with AES-256 in GCM or CBC mode
• Use random IVs, appropriate key lengths (minimum 2048-bit RSA or 256-bit AES), and OAEP padding for RSA operations
• Pair encryption with integrity verification; encryption alone does not prevent tampering with data in transit

Never hardcode secrets

• Do not embed cryptographic keys, API keys, cloud credentials, or service tokens in application binaries; a key in a compiled binary will eventually be extracted
• Use platform-provided secure storage such as Android Keystore or iOS Secure Enclave, or fetch secrets at runtime from a secrets management service
• Audit and rotate credentials regularly and apply least-privilege permissions to any key used in a mobile context

Secure all network communication

• Enforce HTTPS for all network traffic with no exceptions; for sensitive endpoints, implement certificate pinning to prevent interception via fraudulent certificates
• Wrap all socket-level communication in TLS; raw unencrypted sockets create network-level exposure even when higher-layer protocols appear secure

Eliminate injection vulnerabilities

• Use parameterized queries or prepared statements for all database interactions
• Validate and sanitize all user input before it reaches backend systems

Protect sensitive data on-device

• Store credentials, tokens, and secrets in the platform keychain or secure enclave
• Avoid writing sensitive data to plaintext logs, local files, or shared preferences
• Minimize the amount of sensitive data stored on-device

Limit permissions and reduce attack surface

• Request only the permissions required for core functionality
• Avoid exposing app components that can be invoked by other applications without explicit validation
• Disable debugging flags and remove insecure configurations before production release

Vet third-party SDKs and open-source libraries

• Audit all third-party dependencies before integrating them and track versions against known CVEs
• Maintain a Software Bill of Materials (SBOM) for the full application supply chain
• Establish a patching cadence; unpatched dependencies are one of the most persistent sources of exploitable risk in mobile apps

Test mobile apps using multiple analysis methods

• Combine static analysis, dynamic testing, and behavioral analysis
• Test applications the way users actually interact with them
• Continuously scan new releases and updates as part of CI/CD pipelines

Q-mast is Quokka’s automated mobile application security testing solution built for teams that need deep visibility, operational speed, and strong compliance. Q-mast performs full-spectrum testing across the mobile software development lifecycle, covering static, dynamic, and interactive analysis, even in obfuscated or binary-only builds. The solution generates a complete, version-specific software bill of materials (SBOM), including embedded libraries, to surface vulnerable components and dependencies with pinpoint accuracy. Designed to fit into modern pipelines, Q-mast integrates with DevOps tools like GitHub, GitLab, and Jenkins. 

What Organizations Should Do to Protect Corporate Data From Risky Mobile Apps

Security teams cannot assume that applications downloaded from official app stores are free from risk. Marketplace approval primarily focuses on functionality and basic compliance, not deep security inspection. Organizations should treat mobile applications as part of their attack surface and manage them accordingly.

Extend security beyond device-level controls

• MDM and Mobile Threat Defense (MTD) tools are valuable, but they primarily evaluate device posture and known threats. 
• Complement these controls with application-level security analysis that inspects how apps behave and interact with sensitive data.

Implement mobile app vetting before deployment

• Analyze apps before allowing them to access corporate data or systems
• Identify vulnerabilities, insecure cryptography, and risky data flows
• Evaluate privacy behaviors and third-party SDK activity
  

Understand mobile app data flows

• Identify what sensitive data an app collects
• Determine where that data is transmitted and stored
• Flag applications that send sensitive information to unexpected destinations
  

Manage mobile supply chain risk

• Maintain visibility into the libraries and SDKs included in enterprise apps
• Track known vulnerabilities and outdated dependencies
• Generate SBOMs to improve supply chain transparency

Continuously monitor app updates

• Security risk can change with every new version of an application
• Re-analyze apps whenever updates are released or dependencies change

Q-scout enables security teams to vet mobile apps while substantiating their decisions with precise, data driven insights. It provides evidence needed to confidently approve or block apps, ensuring compliance, safeguarding privacy, and protecting organizational assets from mobile threats. 

Q-scout seamlessly integrates with MDMs, giving security teams real-time visibility into the mobile apps installed across MDM-managed devices. App inventories are automatically ingested into Q-scout and continuously updated, allowing each app to be analyzed for security and privacy risks as soon as it is added or updated. This ensures that administrators always have an up-to-date, actionable view of mobile app exposure without manual effort.

Bringing Visibility to Mobile App Security

The scale of Quokka’s findings shows that vulnerabilities are not edge cases. These numbers describe an industry that has not yet treated mobile security as a fundamental engineering requirement.

Mobile applications handle authentication, process payments, store health data, access corporate systems, and transmit sensitive information at massive scale. Most organizations still treat mobile apps as trusted software, but Quokka’s data shows that assumption is not accurate.

Request a demo to see how Quokka’s mobile app risk intelligence can reduce the mobile attack surface in your organization.

FAQs

Q1: What are the most common mobile app security issues in the report?
The report points to four recurring problems, unencrypted HTTP traffic, SQL injection, weak cryptographic configuration, and hardcoded secrets. It also shows that third-party dependencies still ship with Critical and High severity CVEs. That mix matters because it covers both code-level mistakes and supply chain risk.

Q2: Why are hardcoded keys such a serious problem in mobile apps?
A key in a compiled binary is a key that can be extracted. Once it is exposed, the impact applies to every user or system protected by that secret, not just one account. The article also calls out hardcoded AWS keys, where a single leak can expose storage, databases, or infrastructure access.

Q3: Do app store reviews catch these issues?
No, not at the level the report is describing. App store review processes do not catch the majority of these vulnerabilities, because they focus on functionality and basic compliance rather than deep security inspection. That is why app-level testing and dependency analysis matter.

Q4: How should organizations vet mobile apps before deployment?
Treat mobile apps as part of the attack surface, not as trusted software by default. Check how the app handles sensitive data, review its dependencies with an SBOM, and re-scan every time the app or its libraries change. That approach catches risks that device-only controls miss.