A mobile app was leaking personally identifiable information (PII) without anyone knowing. The source? A third-party analytics library. No one on the development team had changed anything. The configuration was untouched. But the library was quietly sending user credentials to its backend dashboard, where they were stored and exposed.
This wasn’t a theoretical risk. It was a real case uncovered by our security engineering team and resolved in close collaboration with the client’s developers. And it’s a reminder of something many teams overlook: your biggest security risk might not be in your own code.
In today’s software ecosystem, third-party integrations are everywhere—used for analytics, payments, messaging, and more. They help teams move fast, but they also introduce risks you can’t fully control. Most SaaS providers expose your integrations over the internet, meaning that their infrastructure vulnerabilities can become your data breaches.
And yet, most product teams still scope penetration tests and threat models only around their own code, ignoring the supply chain behind it.
This article breaks down the case in detail—what happened, how we caught it, and what your team can learn to avoid a similar breach.
- Discovery and initial response
- Manual detection
- Investigation process
- Development team’s response
- Remediating vulnerability
- Communication with vendor
- Key observations
- Security issues during holidays
- Lessons learnt
- Summary
Discovery and initial response #
Our security engineering team has been working with a specific client for many years, leading product security efforts and shaping the secure software development process (SSDLC) for one of their mobile apps.
We discovered a vulnerability during a routine review of release candidates as a part of the SSDLC process. We check all release candidates, focusing not only on new functionality, but also ensuring that all parts of the application work as expected. This includes network traffic analysis, simulating poor connectivity, verifying UI functionality, and more. We monitor all communication between the app and third-party backends. While this might seem overwhelming, it is crucial for security.
Manual detection #
During one such review, we used Burp Suite to manually look for interesting data patterns in network traffic. By setting specific filters (e.g., such as searching for terms like “password” in request bodies), we identified that sensitive information was being sent to third-party backends. Figure 1 displays a screenshot example of the HTTP history filter settings being used.
Figure 1. HTTP history filter settings
To confirm this leakage, we inspected the HTTP request containing the user credentials that the analytics library sent to its backend. Figure 2 shows the full request payload in JSON format, including user credentials (email and password) and other identifying parameters — all of which have been redacted in the screenshot to protect user privacy and sensitive app details.
Figure 2. HTTP request payload showing user credentials sent to analytics backend
Precise filtering allowed us to discover that the analytics library was leaking customer data to its backend. This initial finding triggered a deeper investigation. Even a simple, regularly performed check like this can help catch potential issues early.
Investigation process #
Upon discovery, our team began investigating the root cause of the data leak. We checked the initial configuration of the library and analytics rules and confirmed that the development team hadn’t recently made any substantial changes. The only notable change was a minor automatic version update of the analytics library.
This update—which occurred in the previous release without issues—was now causing a problem.
Figure 3. Discovery and initial response timeline
A recent update introduced an unexpected issue. The cause was traced to a third-party analytics library that had been logging and transmitting user credentials as parameters during login. This sensitive data was then sent to the backend, creating a significant security risk. Neither we nor the client had control over this change, as it stemmed from an automatic library update.
The SSDLC process helps mitigate security weaknesses before they become incidents. Read how we built the SSDLC process from scratch for proactive security.
Development team’s response #
The development team was immediately notified and began working on the incident. Despite the incident occurring close to the holidays, on 20 December, the team swiftly initiated the following actions:
- Stopped the leak by downgrading the library and publishing a hotfix of the application to the stores. This happened within one day after the issue had been identified.
- Prevented further leaks by migrating the user base to the application’s fixed version.
Figure 4. Fix implementation timeline
Remediating vulnerability #
Our next step was to understand its full impact. By identifying the vulnerable app version, we determined which part of the client’s user base was affected. This assessment occurred after the application’s fixed version had already been published to the app stores.
Steps we took to remediate the vulnerability:
- Version analysis and user segmentation: We analysed user data to identify those running the vulnerable versions of the app.
- Immediate mitigation: Using the force-update feature, the client development team promptly distributed the patched version to all affected users. This minimised the vulnerability’s window of impact and ensured user safety without relying on manual updates.
- Monitoring the update: Post-update, we monitored the deployment to ensure all impacted users had successfully upgraded to the secure version of the application. Any issues in the update process were immediately addressed.
By taking these steps, we aimed to distribute the patched application and update all users as soon as possible. While these steps addressed the immediate risk, one of our concerns was preventing similar incidents in the future. To avoid recurrence, we:
- Implemented local data scrubbing: Configured the app to strip any sensitive fields (e.g., user credentials, tokens, PII) from outgoing network requests. We tested this in practice by sending crafted payloads and confirming that no sensitive data was transmitted.
- Enabled server-side data scrubbing: Applied equivalent filters on the analytics backend to catch and discard unexpected sensitive parameters before processing.
Additionally, we updated our regression checklist for release candidates to include scanning for critical data patterns (passwords, tokens, PII) in every build.
The only remaining task was to deal with the current leak.
Communication with vendor #
Working with the data leak: The development team communicated with the analytics vendor’s security and support teams to verify fixes. They cleaned data from the analytic dashboard, then reviewed and improved the policies that prevent logging data in the dashboard.
As a result, the development team configured policies on both the client side (in the application code itself) and the server side (on analytics servers) to prevent all data containing keywords, specific to the client’s application, from being logged.
Figure 5. Vendor Collaboration and Final Resolution timeline
Key observations #
The development team maintained good dependency management practices and closely monitored the quality of the imported dependencies. The library had a good reputation and no known public vulnerabilities. Although the update was minor and carried out as expected, the vulnerability was found during a deep review.
This case highlights how adhering to best practices in dependency management is crucial for overall security and can significantly reduce risks. However, even best practices cannot guarantee immunity from all security issues—even routine updates can introduce unforeseen issues.
Security issues during holidays #
The timing of the incident, just before the winter holidays, added complexity. Some security engineers from our team, client developers, and library maintainers were already on vacation. It was hard to respond swiftly. This scenario confirms the need for continuous vigilance and preparedness, especially during holiday periods.
Lessons learnt #
This incident highlights several important practices for managing vulnerabilities in mobile apps:
- Monitoring and automation: Regular monitoring of communication between the application and third-party services—especially when automated—can help detect vulnerabilities early. Tools like Burp Suite and scripting can be very useful.
- Preparedness: Having a prepared and responsive team is crucial for incident management. Quick response times can significantly mitigate an incident’s impact.
- Patch management and regression testing: Thorough testing of patches, even minor updates, is essential to avoid introducing new vulnerabilities. It’s easier to automate regression testing for the web than mobile applications, but both still need it.
- Force-update capability: Implementing a force-update feature in mobile applications is vital to ensuring that all users receive critical updates immediately, protecting them from discovered vulnerabilities.
Need a boost in mobile application security?
Connect with our security engineers!
Summary #
This incident demonstrates the importance of balancing proactive security measures with quick incident response. If you want to tackle the risks that come with third-party integrations, you need a mix of a solid response plan, regular security check-ups, and a well-planned SSDLC process.
Build a security-first mindset across your whole team. This means weaving security into every step, from thorough pre-release checks to keeping a close eye on how your app talks to third-party services. We’ve seen firsthand how this all-around approach to security helps navigate tricky situations and keeps sensitive data safe, even when things don’t go as planned.
