π Bug Bounty Testing Methodology
A systematic approach to finding security vulnerabilities - follow these 5 phases for comprehensive testing
π Phase 1: Reconnaissance
π― Goals
Understand the target application's architecture, technology stack, and attack surface.
Gather as much information as possible without directly interacting with the target yet.
π What to Test
- Subdomain enumeration - Find all subdomains and services
- Technology fingerprinting - Identify frameworks, servers, CDNs
- Third-party integrations - APIs, payment gateways, analytics
- Public information - GitHub repos, job postings, social media
- DNS records - MX, TXT, SPF, DMARC records
- IP ranges & ASN - Network infrastructure mapping
- Historical data - Wayback Machine, certificate transparency logs
π οΈ Tools
# Subdomain enumeration
subfinder -d target.com -all -recursive
assetfinder --subs-only target.com
amass enum -d target.com
# DNS reconnaissance
dig target.com ANY
dnsenum target.com
# Certificate transparency
curl -s "https://crt.sh/?q=%25.target.com&output=json" | jq
# Technology detection
whatweb target.com
wappalyzer
# Wayback URLs
waybackurls target.com
gau target.com
β οΈ Common Mistakes
- Skipping reconnaissance and jumping straight to testing
- Not documenting findings systematically
- Ignoring subdomains and focusing only on the main domain
- Not checking for exposed credentials in GitHub/Pastebin
- Overlooking mobile apps and their APIs
π Mindset
"The more you know about the target, the better your chances of finding vulnerabilities.
Recon is where most bugs are found indirectly - through forgotten subdomains, exposed services,
and legacy systems."
πΊοΈ Phase 2: Mapping & Enumeration
π― Goals
Map out all endpoints, parameters, and functionality. Understand how the application works,
what data it processes, and how different components interact with each other.
π What to Test
- URL enumeration - Crawl and spider all accessible pages
- API endpoint discovery - Document all API routes and methods
- Parameter discovery - Find hidden parameters in requests
- JavaScript files - Extract endpoints and secrets from JS
- Authentication flows - Map login, registration, password reset
- User roles - Identify different privilege levels
- File upload functionality - Document upload mechanisms
- Input validation points - Catalog all user input fields
π οΈ Tools
# Web crawling
katana -u https://target.com -js-crawl -depth 3
gospider -s https://target.com -c 10 -d 3
# Content discovery
ffuf -u https://target.com/FUZZ -w wordlist.txt
dirsearch -u https://target.com
# Parameter discovery
arjun -u https://target.com
paramspider -d target.com
# JavaScript analysis
subjs -i domains.txt
python3 linkfinder.py -i https://target.com -o results.html
# API enumeration
kiterunner scan https://target.com -w routes.txt
# Proxy/Manual exploration
Burp Suite Pro
OWASP ZAP
β οΈ Common Mistakes
- Relying only on automated tools without manual exploration
- Not testing with different user roles and privilege levels
- Ignoring API documentation or GraphQL introspection
- Missing mobile API endpoints
- Not analyzing JavaScript thoroughly for hidden endpoints
π Mindset
"Every input field, every parameter, every endpoint is a potential vulnerability.
The goal is to know the application better than its developers do."
π Phase 3: Vulnerability Discovery
π― Goals
Actively test for security vulnerabilities using the information gathered in previous phases.
Focus on high-impact bugs first, then work your way through the OWASP Top 10 and beyond.
π What to Test
- Injection flaws - SQL, NoSQL, Command, LDAP injection
- Broken authentication - Session fixation, weak passwords, 2FA bypass
- Sensitive data exposure - API keys, tokens, PII leaks
- XXE & XXE-based attacks - XML external entity processing
- Broken access control - IDOR, privilege escalation, forced browsing
- Security misconfiguration - Default credentials, verbose errors
- XSS - Reflected, stored, DOM-based cross-site scripting
- Insecure deserialization - Object injection attacks
- Known vulnerable components - Outdated libraries and frameworks
- Insufficient logging - Missing security events
- SSRF - Server-side request forgery
- CSRF - Cross-site request forgery
- Business logic flaws - Race conditions, price manipulation
π οΈ Tools
# Automated scanning
nuclei -l targets.txt -t cves/ -t vulnerabilities/
nikto -h https://target.com
# XSS testing
dalfox url https://target.com/page?param=value
XSStrike
# SQLi testing
sqlmap -u "https://target.com/page?id=1" --batch
ghauri -u "https://target.com/page?id=1"
# SSRF testing
ssrfmap -r request.txt
interactsh-client
# Fuzzing
ffuf -u https://target.com/FUZZ -w payloads.txt
wfuzz -u https://target.com/?param=FUZZ -w xss.txt
# Manual testing
Burp Suite Intruder
Burp Suite Repeater
β οΈ Common Mistakes
- Testing only obvious inputs and ignoring edge cases
- Not testing different HTTP methods (GET, POST, PUT, DELETE, PATCH)
- Giving up after a WAF blocks your requests
- Not chaining vulnerabilities for higher impact
- Focusing only on technical bugs and missing business logic flaws
- Not testing mobile apps separately from web applications
π Mindset
"Think like an attacker, not a pentester. Don't just test for textbook vulnerabilities -
understand the business logic and find creative ways to abuse it. The best bugs are often
found by asking 'What if I do this unexpected thing?'"
π₯ Phase 4: Exploitation & Validation
π― Goals
Prove the impact of discovered vulnerabilities with proof-of-concept exploits.
Validate that the bug is real and demonstrate its severity without causing harm.
π What to Test
- Create PoC - Develop working exploits that demonstrate impact
- Test impact - Show data exfiltration, privilege escalation, etc.
- Reproduce reliably - Ensure the bug is consistent
- Document steps - Write clear reproduction steps
- Test fixes - Verify patches don't introduce new issues
- Chain vulnerabilities - Combine bugs for greater impact
π οΈ Tools
# Generate PoC
curl, wget, Python requests
Postman collections
Custom scripts
# Screenshots & recordings
Burp Suite screenshot tool
FFMPEG for video PoC
Browser developer tools
# Traffic analysis
Wireshark
tcpdump
# Exploitation frameworks (for authorized testing only)
Metasploit
BeEF (Browser Exploitation Framework)
β οΈ Common Mistakes
- Not providing enough evidence of impact
- Submitting false positives without proper validation
- Causing damage or data loss while testing exploits
- Not explaining the security impact clearly
- Submitting bugs that are out of scope
π Mindset
"The goal isn't just to find a bug - it's to help the company understand why it matters.
A well-documented PoC with clear impact is worth 10x more than a vague report."
π Phase 5: Reporting & Validation
π― Goals
Write professional, actionable reports that help developers understand and fix the vulnerability.
Maintain good communication throughout the triage and remediation process.
π What to Include
- Clear title - Concise summary of the vulnerability
- Severity rating - CVSS score or platform severity
- Vulnerability description - What the bug is and why it matters
- Affected components - URLs, endpoints, parameters
- Reproduction steps - Clear, numbered steps to reproduce
- Proof of concept - Code, screenshots, videos
- Impact analysis - Real-world consequences
- Remediation advice - How to fix it (optional but helpful)
- References - OWASP, CVE, CWE links
π οΈ Report Template
**Title:** [Type] in [Feature] leads to [Impact]
**Severity:** High
**Description:**
The application is vulnerable to [vulnerability type] in the [affected feature].
An attacker can exploit this to [describe attack scenario].
**Steps to Reproduce:**
1. Navigate to https://target.com/vulnerable-page
2. Enter the following payload in [parameter]: [payload]
3. Observe that [what happens]
4. This allows [describe impact]
**Proof of Concept:**
[Include curl command, screenshots, or video]
**Impact:**
This vulnerability allows an attacker to:
- [Impact point 1]
- [Impact point 2]
- [Impact point 3]
**Remediation:**
To fix this vulnerability, consider:
- [Recommendation 1]
- [Recommendation 2]
**References:**
- OWASP: [relevant link]
- CWE: [relevant CWE]
β οΈ Common Mistakes
- Writing vague or unclear reports
- Not providing enough detail for developers to reproduce
- Being rude or demanding in communication
- Spamming with duplicate or low-quality reports
- Not following up when the team asks for clarification
- Publicly disclosing before the fix is deployed
π Mindset
"You're helping the company, not attacking them. Professional, detailed reports build
your reputation and lead to higher rewards. Remember: triagers are human too - treat them
with respect and patience."
π‘ Overall Best Practices
- Stay organized: Use tools like Notion, Obsidian, or spreadsheets to track targets and findings
- Take breaks: Fresh eyes find more bugs
- Learn continuously: Read writeups, follow researchers, practice on labs
- Focus on quality: One high-impact bug beats ten low-severity duplicates
- Build automation: Create scripts to speed up repetitive tasks
- Stay ethical: Always respect scope, don't cause harm, follow responsible disclosure