🧪 Mobile Report Analysis and Finding Walkthrough
Intro: Security teams often share a scanner export without translating it into engineering decisions. This page shows what a useful mobile report review looks like in practice.
What this page includes
- a sample report slice with eight issues
- commentary on what each issue means
- business impact language
- short remediation guidance
Sample findings set
Reading pattern: the fast triage line stays visible; the longer commentary lives in a collapsible block so the page stays easy to scan during review.
1. Release build is debuggable
Why it matters: lowers the cost of dynamic analysis and tampering.
Business impact: raises fraud and reverse-engineering exposure, especially in regulated or high-value apps.
Short fix: enforce release build flags in CI and verify signed production artifacts.
Open the deeper review note
Use the visible triage line above to decide whether the issue belongs in a release block, a tracked remediation item, or a risk-accepted exception. If the control fails in a production build, confirm whether the weakness is directly exploitable, whether server-side controls reduce the blast radius, and whether the issue can be fixed before promotion.
2. Cleartext traffic allowed
Why it matters: opens the door to insecure transport and weak internal endpoints being used in production.
Business impact: potential credential theft or session exposure on hostile networks.
Short fix: disallow cleartext traffic in production manifests or network security config.
Open the deeper review note
Use the visible triage line above to decide whether the issue belongs in a release block, a tracked remediation item, or a risk-accepted exception. If the control fails in a production build, confirm whether the weakness is directly exploitable, whether server-side controls reduce the blast radius, and whether the issue can be fixed before promotion.
3. Sensitive data written to logs
Why it matters: logs often survive longer and travel farther than developers expect.
Business impact: token and PII leakage into support tooling or device logs.
Short fix: scrub or remove logs in release builds.
Open the deeper review note
Use the visible triage line above to decide whether the issue belongs in a release block, a tracked remediation item, or a risk-accepted exception. If the control fails in a production build, confirm whether the weakness is directly exploitable, whether server-side controls reduce the blast radius, and whether the issue can be fixed before promotion.
4. Hardcoded API key in bundled resources
Why it matters: the app package is recoverable by attackers.
Business impact: direct misuse of backend or third-party services, possible fraud or quota abuse.
Short fix: move secrets server-side, rotate the key, and treat the embedded value as compromised.
Open the deeper review note
Use the visible triage line above to decide whether the issue belongs in a release block, a tracked remediation item, or a risk-accepted exception. If the control fails in a production build, confirm whether the weakness is directly exploitable, whether server-side controls reduce the blast radius, and whether the issue can be fixed before promotion.
5. Exported Android component without strong protection
Why it matters: another app may trigger flows unexpectedly.
Business impact: data exposure or unsafe workflow execution.
Short fix: reduce exported surface and require explicit permissions.
Open the deeper review note
Use the visible triage line above to decide whether the issue belongs in a release block, a tracked remediation item, or a risk-accepted exception. If the control fails in a production build, confirm whether the weakness is directly exploitable, whether server-side controls reduce the blast radius, and whether the issue can be fixed before promotion.
6. Insecure WebView configuration
Why it matters: weak settings can enable script injection or local file abuse.
Business impact: account compromise, content spoofing, or session misuse.
Short fix: disable risky settings, validate origins, and constrain bridge exposure.
Open the deeper review note
Use the visible triage line above to decide whether the issue belongs in a release block, a tracked remediation item, or a risk-accepted exception. If the control fails in a production build, confirm whether the weakness is directly exploitable, whether server-side controls reduce the blast radius, and whether the issue can be fixed before promotion.
7. App allows backups of sensitive data
Why it matters: device-level extraction or migration can expose data not meant to travel.
Business impact: privacy exposure and support burden after device compromise.
Short fix: disable backups or explicitly exclude sensitive data.
Open the deeper review note
Use the visible triage line above to decide whether the issue belongs in a release block, a tracked remediation item, or a risk-accepted exception. If the control fails in a production build, confirm whether the weakness is directly exploitable, whether server-side controls reduce the blast radius, and whether the issue can be fixed before promotion.
8. Weak certificate validation or pinning misuse
Why it matters: insecure validation creates MITM risk, while brittle pinning breaks trust management if done badly.
Business impact: session theft or production outages from rushed cert changes.
Short fix: validate TLS correctly; use pinning only where the operational model supports it.
Open the deeper review note
Use the visible triage line above to decide whether the issue belongs in a release block, a tracked remediation item, or a risk-accepted exception. If the control fails in a production build, confirm whether the weakness is directly exploitable, whether server-side controls reduce the blast radius, and whether the issue can be fixed before promotion.
How to turn this into a release decision
A useful release review asks:
- is any issue directly exploitable in the current build?
- does any issue expose credentials, tokens, or customer data?
- is the issue on a path already protected by server-side controls?
- does the issue belong in a blocking gate or in tracked remediation?
Good blocking candidates
- hardcoded production credentials
- debuggable release build
- cleartext traffic allowed in production
- exported sensitive components without protection
Good non-blocking but tracked items
- low-risk tracker findings
- advisory privacy notes
- medium issues with proven server-side compensating controls
Report handling tips
- keep the raw JSON artifact
- write a short human summary beside it
- record the release decision
- import the raw report into DefectDojo using reimport, not one-off uploads