What Happens During a Web Application Pentest

The next part of Practical Bug Bounty covered the phases of a web application penetration test. The outline starts before testing and continues after the report is delivered:

Agree on the work and the engagement terms.
Define the rules of engagement.
Verify the scope.
Perform the authorized testing.
Write and deliver the report.
Discuss the findings with the client.
Retest fixes when that is part of the agreement.

These are course notes, not a description of a client engagement I've completed. They give me a clearer picture of the work surrounding the technical assessment.

Agree on what will be delivered

The course introduces the Statement of Work, or SOW, and the Master Service Agreement, or MSA.

A SOW describes the specific engagement. It can cover the applications and environments being assessed, the roles and workflows involved, the expected deliverables, timing, assumptions, and fees. A page count may help describe an application, but the behavior behind those pages matters too. Two applications with similar numbers of screens can have very different testing needs.

An MSA generally sets broader terms for the business relationship. Depending on the agreement, those may address confidentiality, responsibilities, liability, payment, and dispute resolution. The documents can divide these subjects differently, so the important part is understanding the actual agreement rather than assuming a heading tells the whole story.

My notes list non-compete language among the possible contract topics mentioned in the course. That is not a standard requirement for every engagement, and whether such a clause belongs in an agreement needs qualified legal review. This post is an overview of the process, not legal advice or a contract template.

Turn scope into clear testing rules

Rules of Engagement, or ROE, describe the operational boundaries. They need to make it clear what may be tested, how testing may be performed, and when it may happen.

Questions worth resolving include which domains, APIs, roles, and environments are in scope; which techniques are prohibited; and who should be contacted if testing causes an unexpected problem. Data handling and stopping conditions also need to be clear before the assessment begins.

Scope verification is more than checking that a supplied URL loads. The target needs to be the intended system, and the party authorizing the work needs authority over it. An application may use third-party services that are not automatically covered by the client's permission.

NIST SP 800-115 provides broader guidance on planning technical security assessments, conducting them, analyzing findings, and developing mitigation strategies. The planning work helps make the technical activity controlled and useful.

Test within the agreed time and coverage

The course gives roughly one to two weeks as an example testing window, depending on the application. That is a planning example rather than a duration that applies to every pentest. Scope, access, complexity, and the agreed depth of testing affect the work.

During the assessment, findings need reproducible evidence and enough context to explain their impact. A record of coverage also matters. If a role was unavailable or a feature could not be tested, that limitation should be visible in the report.

The testing window doesn't justify going beyond the authorization to finish a promising lead. Any expansion needs to be agreed before that additional work happens.

Write a report people can use

OWASP's reporting guidance describes a report that works for both decision-makers and technical staff. It includes scope and limitations as well as findings and remediation guidance.

For an individual finding, the record should help someone reproduce the issue, understand the impact, and make an appropriate change. Sensitive evidence needs careful handling, and unnecessary personal data should be removed or masked.

I can also include a regression-test idea with the remediation: what should the application allow, what should it reject, and how could a test catch the original behavior returning?

Debrief and retest

The client debrief is a chance to walk through the results, clarify priorities, and answer questions about the recommended fixes. The course gives 30 to 60 minutes as an example, with the actual discussion shaped by the findings and the engagement.

Retesting then checks an implemented change against the original issue and its relevant conditions. A finding's status should reflect that evidence. Fixing one reported issue doesn't establish that every part of the application is secure, and additional testing needs to stay within the agreed retest scope.

I finished the section quiz with three out of three answers correct. The section helped connect the technical work to what needs to happen before and after it: clear authorization, useful evidence, a report the client can act on, and verification of the fixes.

Sources and further reading