Web Application Testing Methodology: Working Through a Structured Test

The difference between a thorough web application test and a superficial one is almost never the tooling. It is whether the tester worked through a defined set of categories or poked at whatever looked interesting. A methodology exists to make coverage repeatable and gaps visible — and to let a second tester reach a comparable result.

Information gathering

Every structured test opens here, and skimping shows up later as missed functionality.

Map the application: every page, every parameter, every endpoint, including those reachable only in certain roles or states. Identify the technology stack from headers, cookie names, error pages and file extensions. Find the entry points — every place user input enters, including headers, cookies and hidden fields, which are the ones developers forget are user-controlled.

Look for what was not meant to be published: administrative interfaces, test and staging instances, backup files, source repositories, API documentation, and comments in the markup. Much of this comes from public sources before you touch the application at all, along the lines described under reconnaissance against a public site.

Configuration and deployment

Separate from the code, and frequently where the fastest findings are. Check TLS configuration and certificate validity, security headers, HTTP methods enabled on each path, directory listing, default and sample content left in place, error handling that leaks stack traces and internal paths, and administrative interfaces reachable from the internet.

Also check the infrastructure around the application — cloud storage permissions, subdomain records pointing at services that no longer exist, and management ports exposed alongside the web service.

Identity, authentication, authorization, session

Four related categories, and the place where the most serious findings usually live.

Identity: whether usernames can be enumerated from differing responses, and whether registration and password reset leak account existence.

Authentication: credential transmission, password policy, lockout behaviour, the password reset flow (a recurring source of account takeover), remember-me handling, and whether multi-factor can be bypassed by going directly to a post-authentication endpoint.

Authorization: the big one. Vertical privilege escalation — can a standard user reach administrative functions? Horizontal — can one user access another's records by changing an identifier? Missing function-level checks, where the interface hides a button but the endpoint still accepts the request. This category needs at least two accounts at each privilege level and is where automated tools are weakest, because a tool cannot know that record 1042 belongs to someone else.

Session management: identifier randomness, regeneration at login, cookie attributes, timeout behaviour, and whether logout actually invalidates server-side — the territory covered under session hijacking.

Input handling and business logic

Input validation covers the injection families — SQL, command, template, XML external entity — along with cross-site scripting in its stored, reflected and DOM variants, file upload handling, and server-side request forgery. Automated tools cover much of this well, which is exactly why it should not consume the majority of a manual tester's time.

Business logic is where manual testing earns its cost. Can a workflow step be skipped? Can a price or quantity be manipulated client-side and accepted? Can a limit be exceeded by sending requests in parallel? Can a discount be applied twice? None of these are vulnerabilities in a scanner's sense — the application behaves exactly as coded — and all of them are real.

API endpoints deserve their own pass. They frequently lack the authorization checks the web interface enforces, and they are increasingly the primary interface rather than an adjunct.

Where automation fits

Run the automated tools, then spend the time they saved on the categories they cannot reach. Scanners cover configuration, common injection and missing headers efficiently and reliably. They do not cover authorization logic, business logic, or chained findings where three medium issues combine into full compromise.

The tool categories and what each one sees are covered under DAST, SAST and IAST, and the practical rule is that a scanner's clean report means the easy findings are gone, not that the application is sound.

Reporting

A finding needs reproduction steps precise enough that a developer can confirm it, an impact statement in terms of what an attacker gains, and remediation advice specific enough to implement. Rate risk by what it means to this organization rather than by a generic severity score, and state explicitly which areas were not tested, because unstated gaps read as clean results.

Exam angles

Know the phases: reconnaissance and mapping, configuration review, identity and authentication, authorization, session management, input validation, business logic, and reporting. Recognize authorization and business logic flaws as the categories automated tools miss and manual testing finds. Understand that methodology provides coverage and repeatability, and that a report must state scope and limitations as well as findings.