Post cover image

July 1, 2026

Web Application Penetration Testing — Hunting Vulnerabilities Where the World Can See Them

SQLi, XSS, IDOR, SSRF, and the OWASP Top 10 through the lens of Burp Suite, ZAP, and Gobuster

By R. Mahathi

5 min read

This is Part 6 of my VAPT series. We've covered reconnaissance, scanning, network pentesting, and Active Directory attacks. This time we move to what is statistically the most exposed attack surface in most organisations — the web application.

What Is Web Application Penetration Testing?

Web application penetration testing is the process of actively probing web apps — login portals, APIs, dashboards, e-commerce platforms, anything a browser (or a script) can talk to — for exploitable security flaws. Unlike network pentesting, which targets infrastructure, web app testing targets the logic layer: how the application processes user input, manages sessions, enforces access controls, and communicates with back-end systems.

The industry-standard reference for what to test is the OWASP Top 10 — a regularly updated list of the most critical web application security risks, maintained by the Open Web Application Security Project. It's the framework most clients expect VAPT engagements to be mapped against, and it's what most report findings reference.

Why It Matters

Web applications are the most exposed part of almost any organisation's attack surface because they're intentionally internet-facing. There's no firewall between an attacker and your login page. That exposure, combined with the complexity of modern web stacks (multiple frameworks, third-party APIs, microservices), makes web app vulnerabilities both common and high-impact.

A few patterns that show up constantly in real engagements:

  • Input handling that trusts user data without sanitisation → SQLi, XSS.
  • Access control that's enforced in the UI but not the API → IDOR.
  • Session management that relies on predictable tokens or never invalidates them → broken authentication.
  • Server-side request handling that doesn't validate target URLs → SSRF.

Most of these aren't new classes of vulnerability. SQLi has existed since the late 1990s. They're common not because they're hard to fix, but because they're easy to introduce and easy to overlook in large, fast-moving codebases.

Core Techniques and Tooling

Burp Suite — The Central Platform

Before diving into individual vulnerability classes, Burp Suite deserves its own mention because it's the platform almost everything else in web app testing runs through. Burp acts as an intercepting proxy — all browser traffic passes through it, letting you inspect, modify, and replay HTTP requests in real time.

The core workflow: browser → Burp Proxy → target application. From there, Burp's Scanner, Repeater, Intruder, and Decoder tools handle everything from automated discovery to manual parameter manipulation.

SQL Injection (SQLi)

SQL injection occurs when user-supplied input is embedded directly into a database query without proper sanitisation, allowing an attacker to manipulate the query's logic. In its simplest form:

' OR '1'='1

injected into a login field causes the query to evaluate to true for every row, bypassing authentication. More advanced exploitation can enumerate databases, dump tables, read files, or (in some configurations) execute OS commands.

In practice, manual probing is usually followed by automated exploitation using sqlmap:

sqlmap -u "http://target.com/page?id=1" --dbs --batch

This enumerates all databases on the back end — a one-liner that, when it hits, tends to make the most dramatic slide in a client presentation.

Cross-Site Scripting (XSS)

XSS occurs when an application reflects user input back into the browser without encoding it, allowing an attacker to inject JavaScript that executes in the victim's browser context. Three main variants:

  • Reflected XSS — payload is in the URL/request and reflected immediately in the response. Requires tricking a victim into visiting the crafted URL.
  • Stored XSS — payload is persisted in the database and executed every time the affected page loads for any user. Higher impact.
  • DOM-based XSS — payload is processed by client-side JavaScript, never touching the server. Harder to detect with server-side scanning.

A basic test payload:

<script>alert('XSS')</script>

That alert box appearing in a browser is the classic proof-of-concept — but the real severity comes from what you can do once script execution is established: session cookie theft, keylogging, redirecting users to phishing pages.

Insecure Direct Object Reference (IDOR)

IDOR is an access control failure where an application exposes a reference to an internal object (a database record, a file, a user account) and doesn't verify that the requesting user is authorised to access it.

The classic example:

GET /api/invoice?id=1042

Change 1042 to 1041 and if the application returns another user's invoice — no error, no access denied — that's an IDOR. It's a logic flaw, not a code injection vulnerability, which is why automated scanners frequently miss it and manual testing is essential.

Burp's Repeater and the Autorize extension make IDOR hunting systematic: capture a request as User A, modify the identifier, replay as User B (or unauthenticated), and compare responses.

Broken Authentication

Broken authentication covers a family of weaknesses in how applications handle login, sessions, and credential management:

  • Weak or default credentials accepted.
  • No account lockout after repeated failed attempts (brute-forceable).
  • Session tokens that are predictable or don't expire after logout.
  • Passwords transmitted or stored without proper hashing.

Gobuster is useful at this stage for discovering login portals, admin panels, and authentication endpoints that might not be linked from the main application:

gobuster dir -u http://target.com -w /usr/share/wordlists/dirb/common.txt -x php,html

Finding a /admin, /staff-portal, or /backup-login endpoint that the client forgot existed is a recurring real-world finding.

Server-Side Request Forgery (SSRF)

SSRF occurs when an application fetches a remote resource based on a URL provided (directly or indirectly) by the user, without properly validating or restricting that URL. An attacker can supply an internal URL:

https://target.com/fetch?url=http://169.254.169.254/latest/meta-data/

That address is the AWS instance metadata endpoint — a classic SSRF target that can leak cloud credentials, IAM roles, and instance configuration data. The same technique can be used to probe internal services behind firewalls that the attacker can't reach directly.

SSRF has climbed steadily up the OWASP Top 10 as cloud-hosted architectures have become the norm, because the internal networks behind cloud applications often contain metadata services and internal APIs that assume no external access is possible.

OWASP ZAP — The Open-Source Scanner

OWASP ZAP (Zed Attack Proxy) serves a similar role to Burp Suite as an intercepting proxy and scanner, with the advantage of being fully open source and well-suited for integration into CI/CD pipelines for automated security testing. In manual engagements it's used for active scanning (automated crawling and vulnerability probing) alongside Burp's more granular manual tools.

Running a ZAP active scan against a target surfaces common issues — reflected XSS, missing security headers, exposed stack traces — quickly, giving a baseline to build manual testing around.

The Manual vs. Automated Balance

One consistent lesson from web app testing: automated scanners (Burp Scanner, ZAP, Nikto) are excellent at finding the obvious — missing headers, reflected XSS, basic SQLi in common parameters. But they systematically miss logic flaws like IDOR, multi-step authentication bypasses, and business logic abuse because these require understanding what the application is supposed to do and testing what happens when you deviate from that.

The practical workflow is: automated scan to establish a baseline and catch the easy wins, then focused manual testing on authentication flows, access control boundaries, and any parameter that touches user identity or data access.

Closing Thoughts

Web application penetration testing sits at an interesting intersection: the vulnerabilities themselves are well-understood and well-documented, the tooling is mature and accessible, and yet web app findings continue to dominate real-world breach reports. The gap between "knowing what SQLi is" and "finding SQLi in a real application buried three API calls deep" is where hands-on practice earns its keep.

The OWASP Top 10 is a framework, not a checklist — working through it systematically while building intuition about how applications handle trust, input, and state is what turns a scanner operator into a web app tester.

Next up in this series: post-exploitation techniques and how findings at each layer — network, AD, web — chain together into a complete attack narrative.

This post is part of an ongoing VAPT series documenting hands-on offensive and defensive security learning. Previous posts covered reconnaissance/information gathering, scanning/enumeration, network penetration testing, and Active Directory attacks.