Web methodology

An orderly web test avoids blind spots and makes the work reproducible. This is the sequence most engagements and bug bounty programs follow, aligned with the OWASP Web Security Testing Guide (WSTG) and PTES. Each specific vulnerability has its own page; here is the framework that ties them together and the order to attack them in.

1. Scope and rules of engagement

Before touching anything, fix in writing:

In scope / out of scope: domains, subdomains, IPs, APIs, mobile apps.
Exclusions: destructive actions, DoS, real third-party data, mass emailing, social engineering.
Time windows, test data, provided accounts and volume limits (don’t enumerate millions of IDs).
Emergency contact and procedure if you find something critical (e.g. exposed data) or if you accidentally take down a service.

Everything below is done only within that authorized scope.

2. Recon

Passive (see area 01, without touching the target): domains and subdomains (crt.sh, subfinder, amass), ASN/ranges, technologies, emails and employees, leaked repos and secrets, history (Wayback), buckets.
Active: resolution and httpx to see what responds, stack fingerprint (server, framework, WAF, CMS with whatweb/wafw00f), relevant ports.
Content discovery: ffuf/feroxbuster with wordlists (SecLists, raft, by technology), sensitive files (.git, .env, backups), API routes.

3. Attack surface mapping

Proxy everything through Burp and walk the app as a real user (all roles).
Inventory parameters (arjun, paramspider), API endpoints, flows (registration, login, recovery, payment), roles and permissions, and entry points (forms, headers, cookies, uploads, WebSockets).
Identify per-component technologies (template engine, ORM, serialization, CMS) because they condition which flaws to test.

4. Category analysis (WSTG / OWASP Top 10)

Systematically cover, prioritizing by impact:

Access control (IDOR/BOLA, vertical escalation, mass assignment) — usually the most profitable.
Authentication and session (enumeration, brute force, MFA, reset, fixation).
Injections (SQLi, NoSQLi, command, SSTI, XXE, LDAP).
Client-side (XSS, CSRF, clickjacking, CORS, prototype pollution).
Advanced server-side (SSRF, deserialization, LFI/RFI, request smuggling, cache poisoning).
Business logic (fraud, flow skipping, race conditions).
Configuration (security headers, HTTP methods, information exposure, components with known CVEs).

5. Exploitation and evidence

Prove real impact with a minimal, reproducible PoC, without harming or exfiltrating real third-party data. Chain flaws when they multiply impact (IDOR + JWT, XSS + CSRF, SSRF + cloud metadata, open redirect + OAuth). Document each step with requests/responses and screenshots.

6. Scoring and prioritization

Assign severity with CVSS (vector + score) and translate to business impact (what data, how many users, what harm). Prioritize exploitable, high-impact issues over theoretical ones.

7. Reporting

Each finding: title, severity (CVSS), description, business impact, detailed reproduction steps, evidence (requests/screenshots) and concrete, actionable remediation. Add a non-technical executive summary. A good report is half the job (see area 20, Bug Bounty).

8. Retest

After the fix, re-verify each finding and document whether it’s resolved, mitigated or still open.

Base tooling (by phase)

Recon        subfinder, amass, httpx, whatweb, wafw00f, nuclei, crt.sh, gau/waybackurls
Content      ffuf, feroxbuster, dirsearch, SecLists
Mapping      Burp Suite (proxy), arjun, paramspider
Exploitation Burp (Repeater/Intruder/Turbo Intruder), sqlmap, dalfox, commix, jwt_tool
Support      PayloadsAllTheThings, HackTricks, browser DevTools

Blue Team perspective

The same walkthrough works for defensive auditing: review access controls, input/output validation, session management, security headers, logging and the detection capability for each attack. Each page includes its Blue Team section with detection, telemetry and hardening.