App Pen Testing: Nmap & Burp Suite in 2026

App security is not a luxury; it’s an absolute necessity. With the proliferation of mobile and web applications, ensuring their resilience against cyber threats has become paramount, and effective penetration testing is the only way to truly gauge that resilience. So, how do you systematically uncover those hidden weaknesses before malicious actors do?

1. Initial Reconnaissance and Information Gathering

Before you even think about launching an attack, you need to understand your target. This phase is all about gathering as much information as possible about the application, its infrastructure, and its dependencies. I always tell my team, “You can’t hit what you can’t see.” We start with public information, then move to network-level insights.

Tools we use: Nmap and Maltego are indispensable here. Nmap helps us discover open ports, services running on the server, and even the operating system fingerprint. Maltego, on the other hand, excels at correlating open-source intelligence (OSINT) to build a comprehensive picture of the target’s digital footprint.

Exact settings for Nmap: For a comprehensive scan, I typically run nmap -sS -sV -O -p- [target_IP]. The -sS performs a SYN scan, which is stealthier. -sV probes open ports to determine service/version information, and -O attempts to guess the operating system. The -p- option scans all 65535 ports, which can be time-consuming but offers the most thorough initial sweep. For app-specific testing, I’d then narrow down to common web ports like 80, 443, 8080, and 8443.

Screenshot description: Imagine an Nmap output showing a target server with port 443 (HTTPS) open, running Apache 2.4.54, and identified as a Linux kernel 5.x. This immediately tells me I’ll be looking for web application vulnerabilities and potential Linux-specific exploits.

Pro Tip: Don’t neglect subdomains. Many organizations host less secure applications on subdomains that attackers often overlook. Use tools like OWASP Amass or Subfinder to enumerate them.

2. Dynamic Application Security Testing (DAST)

Once you have a lay of the land, it’s time to interact with the application itself. DAST focuses on identifying vulnerabilities by simulating attacks against a running application. This is where we see how the app behaves under stress and how it handles malicious input.

Tools we use: Burp Suite Professional is the undisputed king of web application penetration testing. Its proxy functionality allows you to intercept, inspect, and modify all HTTP/S traffic between the browser/app and the server. For mobile apps, especially Android, we often pair Burp with a rooted device or an emulator configured to proxy traffic through Burp.

Exact settings for Burp Suite:

1. Configure your browser or device to use Burp Suite’s proxy listener, typically 127.0.0.1:8080.
2. Ensure “Intercept is on” in the Proxy tab.
3. Navigate through the application, paying close attention to all requests and responses.
4. In the “Target” tab, scope the target to your application’s domain. This helps filter out irrelevant traffic.
5. Use the “Repeater” for manual manipulation of requests, testing for SQL injection, Cross-Site Scripting (XSS), and Broken Access Control. For example, I might take a legitimate request, change a user ID parameter, and see if I can access another user’s data.
6. The “Intruder” is excellent for brute-forcing parameters or fuzzing inputs. I’d set up an Intruder attack to test for common username/password combinations on a login form or to discover hidden directories.

Screenshot description: A Burp Suite “Repeater” tab showing a modified GET request for /api/v1/users?id=2 where the original request was for id=1. The response shows user data for ID 2, indicating a potential Insecure Direct Object Reference (IDOR) vulnerability.

Common Mistake: Many newcomers focus solely on automated DAST scanners. While those are fine for initial checks, they often miss complex logical flaws or chained vulnerabilities. You absolutely must perform manual testing with a tool like Burp Suite; it’s non-negotiable for thoroughness. Neglecting comprehensive app security measures can lead to significant risks.

3. Static Application Security Testing (SAST)

While DAST looks at the running application, SAST examines the application’s source code, bytecode, or binaries without executing it. This is particularly effective at finding vulnerabilities early in the development lifecycle, allowing for “shift-left” security.

Tools we use: For modern applications, especially those built with common frameworks, SonarQube is a strong contender. It integrates well into CI/CD pipelines and supports a wide range of languages. Other commercial SAST solutions like Checkmarx or Fortify are also popular in enterprise environments.

Exact settings for SonarQube (simplified for a typical scan):

1. Set up a SonarQube server and install the necessary language plugins (e.g., Java, Python, JavaScript).
2. Integrate the SonarScanner into your build process. For a Maven project, it might look like mvn sonar:sonar -Dsonar.projectKey=my-app -Dsonar.host.url=http://localhost:9000 -Dsonar.login=YOUR_TOKEN.
3. Configure quality gates within SonarQube to fail builds if critical vulnerabilities or code smells exceed predefined thresholds. For example, we often set a rule that zero “Blocker” or “Critical” issues are allowed on new code.

Screenshot description: A SonarQube dashboard showing a project overview with “New Code” metrics, highlighting 3 “Critical” security hotspots and 5 “Major” bugs, along with a “Security Rating” of ‘D’.

Pro Tip: Don’t just run SAST and forget about it. Review the findings critically. SAST tools can have false positives, so human analysis is crucial to differentiate real vulnerabilities from benign code patterns.

4. Mobile-Specific Testing (for iOS/Android Apps)

Mobile applications introduce unique attack surfaces not present in web apps. This includes client-side storage, inter-app communication, and device-specific security controls. I recall a client last year whose Android app stored unencrypted user tokens in shared preferences; a simple rooted device and adb shell command exposed all of it. That’s why mobile-specific tools are vital.

Tools we use: Frida and Objection (which builds on Frida) are invaluable for runtime manipulation of mobile apps. For static analysis of Android apps, APKTool and Jadx help in decompiling APKs to review code and resources.

Exact commands/settings for Frida/Objection:

1. Ensure you have a rooted Android device or jailbroken iOS device (or an emulator/simulator).
2. Install Frida server on the device.
3. On your host machine, install Frida and Objection via pip: pip install frida-tools objection.
4. To explore an Android app’s runtime: objection, gadget "com.example.myapp" explore. This attaches Objection to the running process.
5. Inside the Objection console, you can perform various tasks:
   • android sslpinning disable: This is critical to bypass SSL pinning and allow Burp Suite to intercept encrypted traffic.
   • android hooking list classes: Lists all classes in the application, helping you identify interesting areas.
   • android hooking search methods "login": Searches for methods containing “login” to find authentication logic.
   • android hooking set_method_return_value "com.example.myapp.Auth.isLoggedIn" false: A powerful command to force a method to return a specific value, testing access controls.

Screenshot description: An Objection console output showing the successful bypass of SSL pinning for an Android application, followed by a listing of hooked classes related to user authentication, demonstrating runtime manipulation.

Common Mistake: Relying solely on network-level analysis for mobile apps. Many vulnerabilities reside within the app’s client-side logic, data storage, or how it interacts with the operating system. You simply cannot ignore the local attack surface. Proper secure user authentication is crucial to prevent common mobile app vulnerabilities.

5. Vulnerability Management and Reporting

Finding vulnerabilities is only half the battle. The other, equally critical half is communicating those findings effectively and ensuring they get fixed. We ran into this exact issue at my previous firm where a brilliant penetration tester found critical flaws, but his report was so technical and jargon-filled that the development team couldn’t understand the impact or remediation steps. That’s a failure, even if the testing was perfect.

Key elements of a strong report:

1. Executive Summary: A high-level overview of the findings, focusing on business impact and overall risk. This is for the decision-makers.
2. Detailed Findings: Each vulnerability gets its own section. Include:
   • Vulnerability Name & CVE (if applicable): Clear identification.
   • Description: Explain what the vulnerability is.
   • Impact: What could an attacker do? Data breach? Account takeover?
   • Proof of Concept (PoC): Step-by-step instructions (with screenshots and request/response logs) on how to reproduce the vulnerability. This is absolutely essential.
   • Remediation: Specific, actionable advice on how to fix it. Don’t just say “fix XSS”; explain how to implement proper input validation and output encoding.
   • Severity: Typically using CVSS (Common Vulnerability Scoring System) scores (e.g., 9.8 Critical).
3. Risk Rating: A combination of severity and likelihood, often presented in a matrix.
4. Recommendations: Broader security recommendations for the organization.

Example Case Study: Last year, we conducted a penetration test for a financial services client’s new mobile banking app. Our DAST and mobile-specific testing uncovered a critical authentication bypass. By manipulating a specific API endpoint using Burp Suite and Objection, we could bypass the second factor authentication (2FA) for any user, simply by altering a boolean parameter in the request body from "2fa_verified": false to "2fa_verified": true. This allowed full account takeover. The finding was rated CVSS 9.8 Critical. Our report included detailed steps, a screenshot of the modified request in Burp, and the successful login response. We recommended immediate hotfixing of the API endpoint to validate 2FA server-side and implement rate limiting. The client deployed a fix within 72 hours, preventing potential fraud impacting thousands of users. This saved them an estimated $5 million in potential losses and reputational damage.

Pro Tip: Hold a debriefing session with the development team. Walk them through the critical findings. It fosters collaboration and helps them understand the “why” behind the fixes, leading to better AI app security practices long-term.

In conclusion, successful app penetration testing is a methodical, multi-faceted process that combines automated tools with critical human insight. It’s about thinking like an attacker, meticulously exploring every angle, and then translating those technical findings into actionable intelligence for your development team. Don’t just run a scanner and call it a day; true security comes from deep, informed investigation. This proactive approach is key to safeguarding apps from evolving threats.