Mobile devices are generally well protected.
Modern operating systems isolate apps, encrypt storage, and restrict access by default.
Data leaks usually happen for quieter reasons.
They come from decisions made during development, testing, and operation.
Mobile apps handle more data than most realize
It’s common to think of Apps on Mobile Devices as collecting little, if any, sensitive data. However, even the most simplistic applications collect and handle sensitive information about Users. Examples of this include Email Addresses, Phone Numbers, Location Data, Authentication Tokens, Payment and Subscription Information, and Usage and Behavioral Data.
In addition to being widely shared and collected by Developers, there are many ways that Data can leak out of devices through less secure channels.
Trust is spread across too many places
Mobile apps rarely operate alone.
They depend on:
1. Backend APIs
2. Cloud storage
3. Analytics services
4. Advertising and SDK providers
5. Crash reporting tools
Each integration expands the data’s exposure.
Many leaks occur outside the app itself.
Insecure network communication
One of the most common sources of data leakage is how apps talk to servers.
Real-World Problem Examples Include: Issues with Certificate Validation (Weak or Missing), Outdated Encryption Algorithms, Unauthenticated API Requests and Exposed Debug Endpoints (all of which do not result in "stealing" data from a mobile device but rather intercepting or requesting it from a mobile device).
Too Many Permissions/Too Much Data Collection
Apps often ask for access to more data than they truly require. There are some related problems that arise from this over-reach, for example: collecting data with no specific purpose for which to use that data; retaining sensitive data unnecessarily; the risk of greater consequences if the user's permission is abused. Ultimately, once a piece of data is available (to anyone) it becomes vulnerable to exposure.
The improper use of local storage
Cache data is frequently stored to provide improved performance and convenience. Problems result when:
1. Tokens are stored as plain text
2. Sensitive files are written to publicly accessible storage
3. Old data remains in existence
4. Debug logs contain private information
A leak could occur long after the completion of the first session.
Poor Management of Local Storage
The frequent use of data caching can help to improve application performance, but this convenience comes at a cost. Some of the most common data-related issues caused by poor management of local storage are when:
1. Tokens are stored in plaintext format
2. Sensitive files are written to a shared location
3. Old data is never purged or removed
4. In logs from debugging, there are elements of personal identifying information
The leak could occur many months after the original session has ended.
Blind Spots Created by Third-Party Code
Mobile applications often rely heavily on third-party code and use many libraries externally. Common problems related to this excessive reliance on third-party software include:
1. Libraries that send data to a third-party website/server.
2. Libraries that change their behavior or functionality over time.
3. Newly released libraries are not thoroughly examined before they can be used in an application.
4. Some libraries may collect data outside the scope of the application.
In some cases, data leaks have occurred after organizations have learned about the exposure of their data when a library they relied on suddenly switched from one hosting service to another.
Real-world examples
Example 1: Location Information Leak
A fitness app passed location information to analytic platforms.
The importance of the leak:
1. Users did not know about it
2. Location information could potentially be matched with people's identities
3. There were no clearly defined retention practices for the data
Example 2: Token Leakage via Logs
An application stored authentication tokens in its logs as part of the error handling process.
The importance of the leak:
1. Logs are available to people with access to jailbroken phones
2. Tokens had long validities (could be used for a lengthy period of time)
Example 3: Unsecured Backend API
A generic, unprotected mobile app gave access to complete user profiles via the API.
The importance of the leak:
1. Individuals could see user profile data without using the app
2. There were no limits on the number of requests made to the backend API by an individual
Why are Data Leaks Hard to Find?
Most of the time, when mobile data is leaked, few traces are left behind.
Reasons include:
1. Data sent over legitimate channels
2. Leaks occurring inside third-party services
3. Limited logging on mobile devices
4. Long delays between exposure and discovery
By the time an issue is found, data may already be copied elsewhere.
What reduces data leakage
Apps that are less likely to leak sensitive or private information usually follow these four simple rules:
1. Only collect data that you absolutely require for your App.
2. Protect all API access against unauthorized access in consent and security level to the same extent that web-based app is done.
3. Continuously monitor third-party libraries used in your App for any potential security loopholes/vulnerabilities.
4. Encrypt all Sensitive Data on Device.
By following these best practices as part of your development lifecycle you will greatly minimize the risk of exposing sensitive information to unauthorized access.
What to take away
Mobile applications do not leak information due to their being inherently risky; rather, they leak because the route that the data takes is complex and oftentimes cannot be seen.
The more you know about the route data takes, the less it is necessary to harden your device.
When you handle your data in a responsible method at every level, the risk of leaks is diminished and thus, easier to control.
