Mobile App Security Audit: SAST, DAST, and OWASP Assessment

Mobile App Security Audit: SAST, DAST, and OWASP Assessment

We start an audit not by launching tools, but by understanding what exactly we are protecting. A fintech app with biometric login and a medical tracker that writes to HealthKit have different threat models, different testing priorities, and different scope. Over 5 years and 50+ mobile app audits, we adapt our approach to each product. The standard baseline is OWASP Mobile Top 10 — a framework for covering the major vulnerability classes, not a checkbox checklist. Accounting for the app’s specifics lets us focus on truly critical vulnerabilities — for example, missing Certificate Pinning in a fintech app is far riskier than in a game.

The audit process includes both static and dynamic analysis. Their combination gives a complete picture: SAST finds code vulnerabilities, DAST finds runtime flaws. Below is a comparison of the two approaches.

SAST is on average 3 times faster than DAST, but DAST catches runtime errors that SAST misses. Combining them gives us coverage of 95% of typical vulnerabilities.

How the Mobile App Security Audit is Performed

The audit consists of five stages: threat modeling, SAST, DAST, evaluation of defenses (jailbreak detection, anti-debugging, certificate pinning), and report preparation. Let’s look at the key stages in detail.

Static Analysis (SAST)

The first stage is analysis without running the app. Decompilation of an APK via apktool + jadx yields readable Java/Kotlin code. For iOS, we use IDA Pro or Ghidra for the binary, class-dump for Objective-C headers, and strings to search for hardcoded secrets.

During static analysis we look for:

• Hardcoded credentials: API keys, tokens, passwords in strings. grep -r "api_key|secret|password" finds the obvious, but jadx reveals deobfuscated class constants.
• Insecure storage: SharedPreferences or UserDefaults for sensitive data, SQLite without encryption.
• Incorrect Android component flags: exported="true" on Activity/Service/BroadcastReceiver without proper intent-filter validation.
• Weak cryptography: DES, MD5 for passwords, ECB mode, zero IV, predictable seed for Random.

For Flutter apps, SAST is harder — we use reFlutter to dump snapshots and dumpapp to restore symbols. At this stage, about 70% of vulnerabilities are found, including 90% of hardcoded key cases.

Dynamic Analysis (DAST)

We run the app on a rooted Android (Magisk) or jailbroken iOS (Checkra1n) device and observe its runtime behavior.

Network traffic. Burp Suite acts as a proxy with its certificate installed in the system trust store. If Certificate Pinning is present, we bypass it with a Frida script that hooks TrustManager. Once decrypted, we check: are sensitive data sent in query parameters? Is authentication required on every endpoint? Are correct headers (Strict-Transport-Security) present?

File system. objection lets us view the app’s files in real time: we look for unencrypted databases, logs containing personal data, cached API responses.

Memory. fridump dumps the heap. Credentials after logout, decrypted payloads, and private keys often live in memory.

Reverse engineering and runtime tampering. We test defenses: jailbreak/root detection, anti-debugging, certificate pinning. If everything is bypassed in 10 minutes using standard Frida scripts, the protection level is minimal.

Which Vulnerabilities Are Most Critical?

Most frequently we find: hardcoded Firebase or AWS keys in strings.xml, missing Certificate Pinning, logging of API requests via Log.d, insecure deep link handlers, missing privacy screen on background (FLAG_SECURE). Rarer but more critical: SQL injection via deep links, insecure deserialization in broadcast receivers, biometric bypass via patching BiometricPrompt.

Reporting and Classification

Each finding receives a CVSS score and an attack vector description — not just "vulnerability found," but "an attacker with physical access to the device can extract the authorization token from an unencrypted database in 15 minutes." Each item includes a concrete recommendation with code examples.

The final report is split into two parts: a technical one (for developers, with code, screenshots, and Frida scripts) and an executive summary (for managers, with priorities and business risks).

Report Contents and Additional Services

• Detailed report with CVSS scores and attack vector descriptions.
• Frida scripts to reproduce the vulnerabilities.
• Remediation consultation.
• Retest after one month.

Process and Timelines

1. Threat modeling.
2. SAST.
3. DAST.
4. Evaluation of defenses.
5. Report preparation.

Minimal audit of a small app (up to 50 screens) — 1–2 weeks. Comprehensive audit of an enterprise app with server side, multiple platforms, and compliance requirements (PCI DSS, HIPAA) — up to 2–3 months. The cost is calculated after an initial scoping call, which assesses the app’s feature set, platforms, and backend complexity.

After the audit, we offer a retest — a verification that the found vulnerabilities are indeed fixed, not just marked as resolved.

Investing in an audit saves money on future fixes: according to statistics, fixing a vulnerability during production costs 30 times more than fixing it during the audit stage. Contact us for a preliminary assessment and get a personalized quote. Order an audit and secure your application.