Hi, I'm Mohanraj and CSE grad . I'm a Security Analyst at a Big4 doing VAPT. Apart from my work, I also develop Web2 and Dapps/ Web3 projects. I'm into all kinds of security testing, but Mobile is my favorite playground. Let's get into it.

Part 2: The Action Phase (Dynamic, API & Reporting)

DAST (Dynamic Analysis Security Testing)

Testing the application while it is actively running.

Dynamic analysis focuses on identifying issues that occur in real-time. To perform this, you must run the app in a controlled environment.

Step 1: Setting Up a Test Environment

  1. Device Setup: Use a rooted (Android) or jailbroken (iOS) device or a well-configured emulator/simulator (Genymotion for Android is excellent). A compromise is often necessary: security features prevent testing, but turning them off can hide vulnerabilities.
  2. Certificate Pinning Bypassing: Many modern apps use SSL/Certificate Pinning, which prevents traffic inspection. Tools like Frida or Objection are required to hook into the runtime and bypass this protection.

Step 2: Network Traffic Inspection (Man-in-the-Middle)

The heart of DAST is intercepting and analyzing traffic between the app and the server.

Tools: Burp Suite (or OWASP ZAP).

  1. Configure the mobile device's network proxy settings to point to your laptop running Burp Suite.
  2. Install Burp's CA Certificate on the mobile device.
  3. Operate the app as a user. Watch the "HTTP history" tab in Burp.

Some of DAST Vulnerability Checklist:

  • Are session tokens sent over insecure channels (HTTP)? (M5)
  • Can you access endpoint functionality without authentication? (M3)
  • Are the HTTP response headers missing security flags (e.g., Strict-Transport-Security)? (M8)

API Security Testing

Focusing on the endpoints the app interacts with.

The mobile application is rarely the final target. It is the entry point. Mobile APIs are frequently plagued by traditional web vulnerabilities.

Step 3: Testing API Vulnerabilities

You have already mapped the API endpoints using Burp Suite during DAST (Step 2). Now, actively test them.

Attack Vectors:

  • IDOR (Insecure Direct Object Reference): Try accessing another user's resource by manipulating IDs in the URL.
  • Injection: Test for SQLi, XSS, or Command Injection in API input fields.
  • Excessive Data Exposure: Analyze API responses (often in JSON) to see if they return full user profiles when only a username is required.

The Deliverable: Reporting

Your testing is only valuable if it leads to action. Your report should be structured for both technical and non-technical stakeholders.

Each finding must include:

  1. Vulnerability Title: e.g., "M9: Local Storage of Insecure PII."
  2. Description: What is the issue?
  3. OWASP Mobile Top 10 Mapping: (e.g., M9).
  4. Risk/Severity: High/Medium/Low.
  5. Proof of Concept (PoC): Steps to reproduce (e.g., screenshots of decompiled code or intercepted traffic).
  6. Remediation Advice: Actionable code fixes for the developer.

Final Thoughts

Mobile Application Security Testing is an evolving field. It requires a mindset that is simultaneously analytical (SAST), behavioral (DAST). A truly secure mobile application isn't built by a single test. It is built by integrating these checks throughout the entire development lifecycle .

This post covers the basics as a starting point. Let me know in the comments if you'd like detailed content on advanced topics like root/jailbreak detection bypass and SSL pinning bypass.