These notes are public, opinionated, and evolving — read abdelkader.ma for the long-form posts.
MethodologyOverview

Methodology

The bug class matters less than the way you work. This is the framework I default to on any web-app engagement, internal or external.

Phase 0 — Before scope

  • Read the rules of engagement twice. Note allowed hours, IP allowlists, out-of-bounds severities, escalation contact.
  • Get an in-scope test account (or two — admin and user) up front. Asking on day three loses you a day.
  • Confirm whether automated scanners are allowed in writing. Some clients forbid them in their MSA without realising; finding out mid-engagement is painful.

Phase 1 — Recon (15–25% of total time)

See Recon Checklist. The core deliverable of recon is a single document containing:

  • Every reachable host
  • Every endpoint per host (from crawl + JS parse + content discovery)
  • Tech fingerprint per host
  • A prioritised “look here first” list (1 sentence per item)

That document is what every later phase consumes.

Phase 2 — Threat modelling (1 hour)

For the application as a whole, answer:

  1. Who can use it — anonymous, authenticated, admin, system?
  2. What does it touch — DB, file storage, mail, third-party APIs?
  3. What is the worst plausible outcome if a low-privilege user becomes admin? If an unauthenticated user becomes any user?
  4. Where are the trust boundaries? Each boundary is a test target.

This step looks slow. It is not. It tells you which 20% of the app to spend 80% of testing time on.

Phase 3 — Test execution

Per endpoint, in this order:

  1. AuthN / AuthZ — IDOR, vertical escalation, horizontal escalation. Use Burp’s Autorize.
  2. Injection — SQL, NoSQL, command, SSTI, LDAP, XPath.
  3. SSRF + file handling — file upload, file download, fetch-by-URL.
  4. Business logic — race conditions, negative quantities, replay, sequence break.
  5. Headers + transport — host header attacks, cache poisoning, CRLF.
  6. Client-side — XSS, CSRF, postMessage, prototype pollution.

Note every “weird but not yet a bug” observation. The pattern from three small weirdnesses is often the real finding.

Phase 4 — Validation

Before writing the report, prove each finding from a clean session. No “works on my machine” findings. Capture:

  • Minimal repro (the smallest curl that demonstrates it)
  • Screenshot or video for visible bugs
  • A timestamp + source IP — for the client’s log correlation

Phase 5 — Reporting

One finding per page. Each finding has:

  1. Title — one line, names the bug and the surface
  2. Severity — CVSS 3.1 vector + rationale (not just the score)
  3. Affected URL / parameter — exact
  4. Steps to reproduce — numbered, ≤ 5 steps
  5. Impact — what an attacker actually does. Avoid “could lead to”
  6. Suggested remediation — specific code/config change, not “implement WAF”
  7. References — CWE, OWASP, vendor advisory

A finding without an impact statement gets downgraded. Always include one.

Phase 6 — Retest

After remediation:

  • Test the fix is effective (the bug is gone)
  • Test the fix is complete (the same class doesn’t appear elsewhere)
  • Test the fix introduced no regression (the feature still works for legitimate users)

All three matter. Skipping any is how “fix introduces new vuln” stories happen.

Related

Common Web PayloadsOverview