What a mobile app pentest report must contain

The three surfaces a mobile pentest tests

A mobile app pentest tests more surfaces than a web application engagement. The client binary runs on a device the tester controls; the device holds the data the app writes to it; and the app communicates with a backend reachable through the same network. Those three surfaces produce three distinct finding categories, and a report that merges them into one list makes it harder to assign ownership or plan remediation.

The standard that organises this work is the OWASP Mobile Application Security project, which covers storage, cryptography, authentication, network communication, platform interaction and code quality. A report that maps its findings to these categories gives a developer a checkable remediation list rather than a narrative of what went wrong.

The separation is also practical. A finding against the client binary is fixed in the app. A finding against device storage is fixed partly in the app and partly through platform configuration. A finding against the backend API belongs to a different team and may require a different sign-off. The article on how a mobile app pentest is run covers how the engagement is structured; this one covers what the report must contain.

What each finding must contain

Finding structure is consistent across all three surfaces, but mobile findings carry fields that web app reports can omit. A finding must have a title that names the class of weakness, the affected component (app version, OS, device model), a severity rating, a full reproduction path, the evidence, the impact, and the remediation. A title like "API security issue" tells a developer nothing; "unauthenticated endpoint returns account data" names the problem and points directly at the fix.

The reproduction path is what separates a usable finding from an observation. For a mobile finding it must name the app version, the OS version, the device or emulator, any prerequisite state (a jailbroken device, a certificate installed, an account in a specific configuration), and the exact steps. A tester who ships the same app to the same device a year later should be able to reproduce the finding from the report alone.

Evidence is the HTTP capture, the extracted file, the decompiled source excerpt, or the memory dump. A paragraph describing what was observed is not evidence. The remediation should state what to change and how to verify the fix, not just the category of problem it falls into.

The table below shows the structure of a single finding, with examples of the fields that most often arrive incomplete.

Static analysis: what the binary should prove

Static analysis takes the app binary and extracts facts without running it. The findings from this phase are code-based: hardcoded credentials or API keys, overly permissive configurations, exported components that should not be reachable from outside the app, and embedded certificates or private keys.

The report should state the tool and version used to decompile the binary, so a reviewer can reproduce the extraction. For Android this is typically jadx or apktool; for iOS it is class-dump combined with a disassembler. An extract from the decompiled output should accompany each finding, showing the line or method where the weakness appears.

The static section should also record the binary integrity checks applied: whether the app validates its own signature at runtime, whether it ships with debugging enabled, and whether the build variant tested is the production release. A debug build with verbose logging and disabled certificate validation is not a representative test subject. The report must state which build was used and how that was confirmed.

A common finding in this category is an API key compiled into a constant or embedded in the string table. The correct remediation is not to obfuscate the string but to remove it from the binary entirely and retrieve credentials at runtime through a secure channel. The finding should name the target configuration, not just the current gap.

Dynamic analysis: runtime and traffic findings

Dynamic analysis runs the app and observes its behaviour. The report section for this phase records what the tester intercepted, instrumented, and modified.

Traffic findings should include the full HTTP exchange: request headers, request body, response headers and response body. A finding that describes "sensitive data in a response" without the response itself is unverifiable. The capture should use a recognisable tool (Burp Suite, mitmproxy), and the finding should name the endpoint, the data returned, and what level of authentication is required to reach it. The backend detection article covers the signals this traffic produces at the server side.

Where certificate pinning was present and bypassed, the report should record the bypass method. A simple bypass via a Frida hook points to a different remediation than a bypass through a custom trust store. For a worked account of this, see breaking the pin: reading a mobile app's API traffic.

Runtime instrumentation findings cover what the app does while running: hooks into authentication methods, calls to cryptographic APIs with weak parameters, and writes to insecure storage. A finding that shows Frida script output or a strace capture is more persuasive than one that describes the class name observed. The API pentest engagement covers the same backend surface when the client has no mobile app, so findings from the dynamic API section of a mobile report map directly to that scope. The article on detecting mobile app attacks covers which API gateway signals correspond to these test activities.

Device storage findings: what the report must show

Device storage findings record what the app writes to the device and whether that data is protected. The report should cover each storage location tested: application sandbox files, SharedPreferences on Android, NSUserDefaults and Keychain on iOS, SQLite databases, and any external storage paths the app uses.

For each location, the finding should show the actual data found and the protection class applied. A finding that shows the SQLite query and its result is more actionable than one that states sensitive data was found in the database. The article on what a mobile app leaves on the phone: tokens in clear text covers the extraction steps for the most common storage paths.

Three things matter to a developer reading a storage finding: where the data is, what protection is applied, and what the correct configuration looks like for that platform. For iOS, the correct storage class for session tokens is kSecAttrAccessibleWhenUnlockedThisDeviceOnly in the Keychain. For Android, the equivalent is EncryptedSharedPreferences backed by the Android Keystore system. The finding should name the target, not just the gap.

The executive summary and the retest record

The executive summary is what a CISO reads before anything else. It should answer three questions: what was the scope of the test, what is the aggregate risk picture, and what must happen first.

The scope statement names the app version, the platforms tested, the account types used, and what was explicitly out of scope. The risk picture is not a count of findings by severity: it is a statement of what an attacker could do, in one or two sentences. "An unauthenticated endpoint returns all user account data" is more useful to a decision-maker than "three high, four medium, two low findings".

The top two or three findings should be named in the summary with their severity and their fix, so a decision-maker reading only the summary knows what the development team must prioritise. The summary is not an introduction to the technical section. It is a standalone risk statement.

The retest record is the last section of the report. It names the build retested, records the date and tester, and states for each finding whether it was confirmed fixed, partially fixed, or still open. A finding marked partially fixed should explain what changed and what remains open. As described in retesting a mobile app fix: the build the tester checked is not the build users run, the build the tester verifies must be the build that ships. A fix confirmed on a development build is not a confirmed fix for the purpose of regulatory evidence.

Mobile app pentest reports as regulatory evidence in the UAE

Organisations in Abu Dhabi and Dubai that handle personal data or provide regulated services face security testing requirements where the report is the primary deliverable an auditor reads.

The CBUAE cybersecurity framework asks financial institutions to conduct security testing of mobile channels as part of their technology risk management obligations. The framework requires evidence that findings were tracked, remediated and verified. The retest record in this article satisfies that requirement: a named tester, a named build, and a confirmed outcome for each finding.

ADHICS, the Abu Dhabi Healthcare Information and Cyber Security Standard, applies to any organisation that handles healthcare data in Abu Dhabi, including the mobile applications through which patients access records and book appointments. ADHICS requires documented evidence of technical security testing at a level of detail that maps directly to the finding format described here: component, evidence, impact and remediation.

For Dubai government entities and their suppliers, DESC requirements address mobile applications in its supply chain security controls. A report structured around MASVS categories and CVSS severity ratings gives a DESC auditor a recognisable format with clear remediation accountability.

The UAE Information Assurance Regulation, published by TDRA, applies federally to entities that meet its applicability threshold. Its technical security testing controls require documented evidence of scope, findings and remediation. A report that does not state what was tested, what was found, and what was verified as fixed is not compliant evidence, regardless of how thorough the testing was.

Frequently asked questions