Mobile Application Penetration Testing Case Study: Android Document Sharing Exposed Offline Files

This white box mobile application penetration test of a field-service Android app examined local data storage and how the app interacts with other apps on the same device. It found that a purpose-built test app could trigger the document-sharing workflow and receive read access to a service report the technician had not selected for sharing.

Engagement	Details
Scope	Android application, local data storage, and inter-application communication
Approach	White box
Effort	6 tester-days, plus 1 tester-day for retesting
Retest	On the corrected build: a clean installation and an upgrade from the earlier version with existing local data

Key takeaways

• Two weaknesses combined: a FileProvider configuration broader than the export folder, and a sharing component that accepted file references from an external invocation without sufficient validation.
• Android’s application isolation was not bypassed; the vulnerable application itself granted access to the file, and the scenario required another app on the same device.
• Static analysis could flag the broad provider configuration, but not whether another app could obtain a usable permission grant.
• After the fix, the test app could no longer retrieve a document outside the permitted sharing flow, and technicians could still share the correct report.

What did the client need tested?

A field-service company provided technicians with an Android application for managing on-site assignments.

To support work in areas with unreliable connectivity, the application stored selected information offline. This included service reports, photographs, equipment-location details, and customer contact information.

Before releasing an updated document-export feature, the organization commissioned a mobile application penetration test. The assessment covered both API communication and interactions with other applications installed on the same device.

Testing used two non-rooted devices and a release configuration representative of production. All records and documents were synthetic test data.

What did the mobile app penetration test find?

The application allowed technicians to share service reports through Android’s standard file-sharing mechanism, using a FileProvider.

Two weaknesses combined to create the exposure.

First, the provider configuration covered a broader directory than the folder intended for document exports. Second, the component handling sharing requests accepted a file reference from an external invocation without sufficient validation.

A purpose-built test application could trigger this workflow and receive read access to a document that the technician had not selected for sharing.

The demonstration used a service report containing a unique marker.

Android’s application isolation was not bypassed. The vulnerable application itself granted access to the file.

The scenario required another application to be installed on the same device. It was not described as a remote takeover of the phone or as access to every technician’s records.

The confirmed impact was limited to files reachable through the affected sharing workflow.

Why didn’t earlier testing and static analysis catch it?

Earlier testing had concentrated on API authorization and encrypted communications. The weakness existed in local interactions between applications.

Static analysis could identify the overly broad file-provider configuration. That warning alone, however, would not establish whether another application could obtain a usable permission grant.

The assessment connected the configuration issue with the behavior of the sharing component and demonstrated the resulting disclosure.

How was the file-sharing flaw fixed and retested?

A dedicated export directory was introduced, containing only documents intentionally prepared for sharing.

The application no longer accepted arbitrary external file references. Sharing was restricted to documents selected through the intended user workflow, and recipients received only the read permissions necessary for that operation.

The development team also reviewed how long exported files remained on the device and how previously granted access was revoked.

A corrected build was available after seven business days.

Retesting covered both a clean installation and an upgrade from the earlier version with existing local data. The test application could no longer retrieve a document outside the permitted sharing flow.

A technician could still deliberately select and share the correct report, confirming that the fix preserved the required functionality.

Each finding’s retest status is recorded in the report, as in section 7 of our sample penetration test report.

Key takeaway

Mobile application security includes the permissions an application grants to other apps. A secure backend and encrypted network traffic do not prevent an unsafe local sharing workflow from exposing data.

Need the same test for your mobile app?

This engagement was a white box test of an Android application, its local data storage, and inter-application communication: 6 tester-days, plus 1 tester-day for retesting. If the API behind your app is the bigger concern, our fintech API penetration testing case study covers the REST API behind a new mobile application.

A mobile app test at Pentestica starts from $3,500 (iOS or Android); see how tester-days translate into a fixed price, or request a pentest quote with your platforms, offline data, and the features you plan to release.