See what a mobile Agentic Deep Scan report looks like
The full, unedited report from a scan of AndroGoat, an intentionally vulnerable Android app used for OWASP training. It shows how each finding is traced to the vulnerable code, proven and fixed.
- Target
- AndroGoat (Android)
- Scan
- Mobile Agentic Deep Scan
- Length
- 200 pages
- Result
- Overall risk: high
Run on an intentionally vulnerable training app. No customer data.
What's inside
Scope and context
What was tested and how, and what the app does, before any finding.
Executive summary
The main risks in plain language, from insecure storage to injection flaws.
Code-level findings
Each finding shows the root cause, the vulnerable code and the exploitation evidence.
Validation and fixes
A second pass confirms each finding, followed by the recommended fix and references.
Annotated finding
One finding, step by step
How the report takes a single finding from the exact build that was tested to the fix. Each step points to its page in the full report.
- Build
AndroGoat 1.0 (1), package owasp.sat.agoat
The report identifies the exact APK by its SHA-256 hash and matches it to commit 1f38398 of the public AndroGoat repository.
Report page 2 - Device
Android 11 emulator
Dynamic tests ran on an Android 11 (API 30) emulator with root access, where the agent installed and launched the app.
Report page 7 - Scope
The Android app only, without test credentials
A Mobile Agentic Deep Scan of the APK, run on 19 and 20 May 2026. iOS, the backend API and web components were out of scope.
Report page 2 - Workflow
The app's own sign-in screens
AndroGoat has no server: its sign-in and PIN screens run on the device. The agent traced what those screens do with the username and password they collect.
Report page 27 - Finding
High: credentials stored in plaintext
Usernames and passwords are written in plaintext to SharedPreferences, an SQLite database and temporary files, one of them on shared storage. Backups are also enabled.
Report page 27 - Evidence
The credentials file, read by another user
The report shows the vulnerable code, then a runtime proof: reading the credentials file on the SD card as a different user returned the full plaintext dump.
Report page 8 - Fix
Encrypt, and keep credentials off shared storage
Disable backups and encrypt the stored data right away. The permanent fix moves credentials to KeyStore-backed EncryptedSharedPreferences, with a code example.
Report page 29 - Verification
How to confirm the fix
Search the decompiled app for credentials passed to storage calls in plaintext, and check that an adb backup no longer exposes readable credential files.
Report page 29
How the agent decided
Why this counts as a risk
A scanner reports whatever matches a rule. Before reporting, the agent checks whether a clue leads to real harm. Here is how it reasoned about one clue in the AndroGoat app.
Step 1
What is this address doing in the app?
The app's resources contain a Firebase database address, androgoat-42597.firebaseio.com, in res/values/strings.xml.
Report page 79Step 2
Does the app actually use it?
No. There is no Firebase library and no code reads this value. A rule-based check would file it as an unused leftover and move on.
Report page 10Step 3
Is the database itself open?
The agent sent one request to the database without logging in. It answered 200 OK and returned a username and a password.
Report page 80Step 4
So, is it a risk?
Yes, High. It doesn't matter that the app ignores the address: anyone who unpacks the app can find the database and read it without an account.
Report page 41Step 5
What fixes it?
Turn on Firebase Authentication and Security Rules so that reading the database needs a signed-in user, and take the unused address out of the app.
Report page 41
Want this report for your own app?
Book a demo and we'll walk you through a scan of your mobile app, web app or API.