A repeatable methodology

The difference between a good tester and a lucky one is a method: working the same reliable way every time, so coverage does not depend on what you happened to think of that day. This lesson is the shape of a web assessment and the public standard that fills in the checklist.

Why method beats instinct#

Instinct finds the bug you are in the mood for. Method finds the bug you would have skipped. When you test the same way each time, you stop forgetting the boring endpoints, you cover every input, and, just as important, you can say what you tested, which is what a client or an exam actually pays for. A report that says "I tested the whole authenticated surface for access-control issues using two accounts" is worth far more than "I found one IDOR", because it tells the reader what is and is not covered.

The phases#

Every engagement, whether a client pentest, a bug-bounty session, or an exam, moves through the same phases you have already learned piece by piece:

1. Scope. Confirm exactly what you are allowed to test, and what you are not, before anything else. This governs every later phase. The next-but-one lesson is entirely about this.
2. Recon. Passive and active reconnaissance: hosts, subdomains, technologies, what the site hands out. The whole Recon path.
3. Map. Turn recon into a picture: every host, app, role, and, crucially, every input point (parameters, forms, headers, cookies, uploads, API endpoints). This is your test plan.
4. Test. Walk the map and, at each input point, apply the relevant bug classes: access control, injection, server-side. The Access, Injection and Server-side paths.
5. Report. Write up what you found so it can be understood, reproduced, and fixed. The last two lessons.

And, as the recon path showed, it is a loop: testing reveals new hosts and endpoints that send you back to mapping. You are not done at "test"; you are done when the surface stops growing and you have covered your map.

Coverage: think in a matrix#

The mental model that stops you missing things is a grid: input points down one side, bug classes across the top. For every input point (this parameter, this form field, this API object id, this upload), ask each question you know how to ask (is authorization checked? does my input stay data? does the server act on it?). You will not test every cell, judgement prioritises, but the grid means a skipped cell is a decision, not an oversight. That is the whole idea of systematic testing.

OWASP WSTG: the checklist someone already wrote#

You do not have to invent the list of what to test. The OWASP Web Security Testing Guide (WSTG) is a free, public, community standard that enumerates the tests for a web application, organised by category: information gathering, configuration, identity and authentication, authorization, session management, input validation (injection, XSS), error handling, cryptography, business logic, and client-side. It is the de-facto syllabus for web testing, and the exam this track prepares you for maps its domains onto it.

Use WSTG two ways. As you learn, it tells you what categories of test exist so you build a complete mental checklist. On an engagement, it is a coverage reference: work its categories against your map and you can be confident you did not forget a whole class of test. You do not memorise it; you know it is there and you lean on it, the way a pilot uses a checklist even after a thousand flights.

Prioritising under limited time#

You never have time to test everything, so method includes triage: spend your attention where impact and likelihood are highest. In practice that means front-loading:

• High-value functionality: authentication, anything touching money, personal data, file uploads, admin functions, and multi-tenant boundaries.
• The soft targets recon found: the staging box, the outdated component, the forgotten subdomain.
• The bug classes that pay: access control first (it is where most findings live and needs only two accounts), then injection and server-side on the inputs that reach dangerous sinks.

A methodical tester with two hours tests the login, the account boundaries, and the money flow, not the marketing pages.

Where this goes next#

A method is only as good as your record of it. The next lesson is note-keeping and evidence: what to write down as you go, so that the finding you spot at hour two is still reproducible and reportable at hour six, and so your report can honestly describe what you covered.