Web application pentest — execution methodology

Web application pentest — execution methodology

TL;DR: A web-app pentest is a time-boxed engagement: scope, recon, mapping, authentication / session, authorization, input handling, business logic, client-side, infra, reporting. Each phase has deliverables; coverage proven via the OWASP Web Security Testing Guide (WSTG) v4.2 checklist plus engagement-specific contract requirements.

What it is

This note is the operator-level playbook for executing a paid web-app pentest, distinct from a hobbyist bug-bounty hunt (testing-methodology-checklists) or vulnerability research (orange-tsai-research-pattern). The goal is defensible coverage within a finite window, mapped to a contract.

Preconditions / where it applies

  • Signed SOW with explicit scope (URLs, IP ranges, accounts, in-scope/out-of-scope, test window)
  • Two or more test accounts per role for IDOR / horizontal escalation
  • Credential channel + emergency contact established
  • Disclosure agreement for any discovered third-party data

Phase-by-phase tradecraft

1. Scope and rules of engagement

Re-read the SOW yourself. Verify:

  • Allowed source IP (some clients firewall everything else)
  • Disallowed payloads (no auto SQLi tools; no DoS; no social engineering)
  • Test window (some clients only allow off-hours)
  • Reporting format (CVSS v3.1 / v4.0, OWASP ASVS L1/L2/L3 mapping, SOC 2 cross-reference)
  • Subprocessor data (e.g., Stripe-tokenised cards — never extract real PANs)

2. Recon and mapping (~10% of budget)

  • DNS, subdomain (subdomain-enumeration), JS endpoint extraction (js-endpoint-extraction)
  • Tech stack fingerprint (tech-stack-fingerprinting) — version-specific CVEs upfront
  • Spider authenticated + unauthenticated; export site map (Burp + custom crawler)
  • Catalogue every endpoint × method into a tracking sheet — your coverage doc
  • Note observed authentication mechanism (cookie, JWT, SAML, OAuth) for later
  • Map roles + permissions matrix from client docs and observed UI

3. Authentication (~10%)

  • Username enumeration on login, password reset, register, MFA prompts
  • Password policy weakness (length, complexity, common-password rejection)
  • MFA bypass: skip-step, race, replay, downgrade (2fa-bypass-deep)
  • Session fixation, predictable session ID, missing HttpOnly/Secure/SameSite
  • Remember-me cookie analysis (remember-me-flaws)
  • Account lockout vs rate-limit absence
  • Password reset token quality + expiry + single-use enforcement
  • OAuth / SAML flow review (oauth-modern-attacks, saml-attacks)

4. Authorization (~15%)

Horizontal across roles, vertical between roles, plus tenant isolation:

  • IDOR walkthrough on every object reference (UUIDs included — they’re not access control)
  • BFLA / BOLA on API methods (bfla, bola)
  • Mass assignment (mass-assignment) — ?role=admin style
  • Forced browsing to admin paths discovered in JS
  • API key scope verification per api-keys doc
  • Tenant boundary: object IDs from tenant A presented under tenant B’s session

5. Input handling and injection (~20%)

Per-parameter, per-method matrix:

6. Client-side (~10%)

7. Business logic (~15%)

  • Race conditions on payment / coupon / signup / quota counters
  • Quantity manipulation (negative, decimal, very large, very small)
  • Workflow bypass (skip step 2 of 5 via direct POST to step-5 endpoint)
  • Promotional code reuse, gift card double-spend
  • Subscription downgrade preserving premium content

8. Infrastructure / configuration (~5%)

9. Reporting (~15%)

  • Executive summary: 1 page, risk-level chart, business impact
  • Per-finding: title, CVSS, OWASP/ASVS reference, repro steps with screenshots, request/response evidence, recommendation, retest criteria
  • Coverage statement: WSTG sections completed + percentage of map exercised
  • Out-of-scope notes: what wasn’t tested and why
  • Appendices: tooling used, accounts/IPs used, test window

Time budget reference (5-day engagement)

| Day | Phase | |—|—| | 1 AM | Scope review, recon, mapping start | | 1 PM – 2 AM | Endpoint catalogue, auth testing | | 2 PM – 3 AM | Authorization matrix, IDOR sweep | | 3 PM – 4 AM | Injection + client-side | | 4 PM | Business logic + infra | | 5 | Reporting, draft review, retest reservation |

Detection and defence — what to flag in report

  • Always include “missing security headers” as low-sev — usually wins easy fix points
  • WAF detection: note if Cloudflare/Akamai/AWS WAF observed and whether bypass tested
  • Rate limiting: document baseline + bypass methods
  • Logging: note if your tests showed up in client SIEM (good purple-team value-add)

OPSEC pitfalls

  • Burp scanner ON for unauthenticated phase = OK; ON for authenticated phase = trash-tier finding noise; turn off active scan after recon
  • Save EVERY request via Burp project file; clients ask for replay later
  • Don’t open private S3 buckets — note presence; do not download content
  • Don’t decrypt third-party tokens (Stripe, Auth0); evidence is “token format matched stripe pk_test_*” without contents
  • Track all created objects; clean up before report submission (rare client request: full restoration)

References

See also: pentest-engagement-execution, pentest-proposal-and-scoping, pentest-report-writing-deep, testing-methodology-checklists, internal-pentest-execution-methodology, burp-suite, oscp-style-box-attack-pattern, bug-bounty-as-career-track