Web Application Testing

Why Web Apps?

Web applications are the most common attack surface in modern networks. Every organization has them, and most are built under time pressure with frameworks that trade security for convenience.

Insecure dependencies, misconfigured servers, weak authentication, and unsanitized input fields. These flaws repeat across every tech stack, every framework, every language.

If it has a login page, it has an attack surface.

Testing Methodologies

There are three approaches to assessing a web application, depending on what information you’re given.

Black-Box Testing

You know nothing. Just a URL. No source code, no credentials, no documentation.

This is:

• The most realistic testing approach
• How bug bounty programs work
• The hardest approach (everything must be discovered)

You start from zero and enumerate everything: tech stack, directories, parameters, APIs, input fields.

White-Box Testing

You have everything. Source code, infrastructure docs, architecture diagrams, credentials.

This is:

• The most thorough approach
• Requires code review skills (reading PHP, Python, Java, etc.)
• Takes longer, but finds more subtle bugs (logic flaws, race conditions)

Grey-Box Testing

Somewhere in between. You might get:

• Valid credentials
• The framework name
• Partial documentation
• Network diagrams

Most real-world pentests are grey-box. The client gives you some info to focus your efforts.

The OWASP Top 10

The OWASP Foundation maintains a list of the ten most critical web application security risks. This is the industry standard for what to test.

The OWASP Top 10 is your checklist. When you find a web app, mentally walk through this list. Most vulnerabilities you’ll encounter in the wild fall into one of these categories.

The Web App Testing Workflow

Every web application test follows roughly the same flow:

1. Fingerprint the stack - What web server? What framework? What language?
2. Discover content - Directory brute-force, sitemap, robots.txt
3. Map the application - Pages, forms, APIs, parameters, authentication
4. Identify inputs - Every field, header, cookie, and URL parameter is a potential injection point
5. Test for vulnerabilities - Injection, XSS, access control, authentication flaws
6. Exploit and escalate - Use findings to gain access, then pivot deeper

Fingerprinting the Stack

Before testing for vulnerabilities, you need to know what you’re attacking.

With Nmap

sudo nmap -p80,443 -sV 10.10.10.50

The version detection reveals the web server software (Apache, Nginx, IIS) and sometimes the backend language.

For deeper enumeration:

sudo nmap -p80 --script=http-enum 10.10.10.50

The http-enum script checks for common directories, admin panels, login pages, and known application paths.

With Wappalyzer

Wappalyzer is a browser extension that passively identifies the technology stack by analyzing what the page serves:

• Web server (Apache, Nginx, IIS)
• CMS (WordPress, Drupal, Joomla)
• Frameworks (React, Django, Laravel)
• JavaScript libraries (jQuery version, Bootstrap)
• CDN and hosting (CloudFlare, AWS)

No extra traffic generated. It just reads what’s already in the page source and headers.

Knowing the stack narrows your search. WordPress? Check for plugin vulnerabilities. jQuery 3.6? Check for known XSS. Apache 2.4.49? Check for path traversal.

Directory Discovery with Gobuster

Hidden files and directories are everywhere. Admin panels, backup files, configuration dumps, upload endpoints. Gobuster finds them by brute-forcing paths with a wordlist.

gobuster dir -u http://10.10.10.50 -w /usr/share/wordlists/dirb/common.txt -t 5

• dir - directory/file brute-force mode
• -u - target URL
• -w - wordlist
• -t 5 - threads (lower = less noise)

Reading the Output

Useful Wordlists

Always run Gobuster early. While you’re manually exploring the app, let Gobuster run in the background. It often finds the path that leads to your initial foothold.

Inspecting the Application

URL Clues

File extensions in URLs reveal the backend language:

Page Source and DevTools

Open the browser DevTools (F12) and explore:

• Inspector - right-click any element to see its HTML. Find hidden form fields, input names, comments
• Debugger/Sources - see all JavaScript files. Look for library versions, hardcoded secrets, API endpoints
• Network - watch all HTTP requests in real time. See response headers, cookies, redirects
• Console - execute JavaScript directly. Test payloads, inspect variables

Response Headers

Click a request in the Network tab and inspect the response headers:

The absence of security headers is just as telling. No X-Frame-Options? Possible clickjacking. No Content-Security-Policy? Easier XSS exploitation.

robots.txt and sitemap.xml

robots.txt tells search engines what not to index. For pentesters, this is a roadmap of hidden paths:

curl http://10.10.10.50/robots.txt

Disallow entries are often admin panels, sensitive directories, or internal tools. The site is literally telling you what it’s trying to hide.

sitemap.xml lists all pages the site wants indexed. Can reveal pages you wouldn’t find through browsing or brute-forcing.