FAQ

Frequently Asked Questions (FAQ)

Common questions from bug bounty hunters, security researchers, and penetration testers using this repository. Can't find your answer? Open an issue or join our Discord community.

---

📋 Table of Contents

• General Questions
• Installation & Setup
• Using Methodologies & Cheatsheets
• Running Tools & Scripts
• Bug Hunting & Reporting
• Contributing & Community
• Legal & Ethics

---

General Questions

What is this repository for?

This is a comprehensive, production-ready knowledge base designed to take you from beginner to advanced bug bounty hunter. It bundles:

• 67+ Methodologies: Step-by-step exploitation guides for web vulnerabilities and technologies
• 68+ Cheatsheets: Quick-reference payloads and commands
• Custom Tools: Automation, recon, and exploitation scripts
• Real Write-ups: Lessons learned from actual bug bounty reports

Unlike generic "awesome lists," every resource here is interconnected and built from real-world testing experience.

---

How is this different from PayloadsAllTheThings or HackTricks?

Feature	This Repository	PayloadsAllTheThings	HackTricks
Full Methodologies (how-to)	✅	❌	✅
Quick Cheatsheets (commands)	✅	✅	✅
Custom Automation Tools	✅	❌	❌
Structured Course Path	✅	❌	❌
Real Write-ups Library	✅	❌	❌
Wordlists Included	✅	❌	❌
CI/CD Workflow Automation	✅	❌	❌

Think of this repo as combining the reference of PayloadsAllTheThings with the depth of HackTricks, plus adding your own custom toolkit and learning path.

---

What's the difference between a Cheatsheet and a Methodology?

This is one of the most common questions, and the distinction is important:

Aspect	Methodology	Cheatsheet
Purpose	Teaches you how to think and exploit	Gives you commands to copy-paste
Depth	Full walkthrough with theory, detection, and exploitation steps	Condensed reference of payloads and syntax
Format	Long-form guide with sections and explanations	Bulleted lists and code blocks
When to Use	When learning a vulnerability for the first time	When you already know the attack and need a quick reminder
Example	"File Upload Vulnerabilities.md" explains content-type bypass, magic bytes, polyglot files, and web shell deployment	"File Upload.md" lists common bypass extensions, MIME types, and exiftool commands

Pro Tip: Study the Methodology first to understand the concept. Then bookmark the corresponding Cheatsheet for quick reference during live testing.

---

I'm a complete beginner. Where do I start?

Follow this path:

1. Read the Code of Conduct — Understand ethical boundaries first
2. Start the Course — course/README.md provides a structured learning path
3. Learn One Vulnerability at a Time — Start with IDOR or XSS; they're common and teach core concepts
4. Set Up Your Lab — Use PortSwigger Web Security Academy or OWASP Juice Shop for safe practice
5. Read Write-ups — Understand how bugs are found in the real world
6. Pick Your First Bug Bounty Program — Start with "responsible disclosure" programs that welcome beginners

---

Installation & Setup

How do I clone and set up this repository?

# Clone the repository
git clone https://github.com/aw-junaid/bug-bounty.git
cd bug-bounty

# No heavy dependencies! Most tools use Python standard libraries.
# For specific tool requirements, check the tool's directory.

The repository is primarily Markdown-based and requires no complex installation. Specific tools have their dependencies documented in their respective directories.

---

What OS do the tools support?

All tools are designed for Linux and macOS. Some Python scripts may work on Windows with minor modifications, but the primary development and testing environment is Unix-based.

For Windows users, use Windows Subsystem for Linux (WSL) for full compatibility.

---

What are the prerequisites for running the Python tools?

Most scripts require Python 3.6+ . Install dependencies per-tool:

# For the XSS scanner
pip3 install requests beautifulsoup4

# For the SQL injection tester
pip3 install requests

# For the recon subdomain enum script
pip3 install requests dnspython

# For the payload generator
# No external dependencies required

Always check the tool's docstring or README for exact requirements.

---

Using Methodologies & Cheatsheets

How do I use a Methodology during a live test?

Follow this workflow:

1. Identify the Technology — Is it PHP? ASP.NET? Does it use GraphQL?
2. Select the Relevant Methodology — Navigate to methodologies/web penetration/ or methodologies/web technologies/
3. Read the Detection Section First — Learn to confirm the vulnerability exists before trying to exploit it
4. Follow the Step-by-Step Exploitation — Don't skip steps; many bypasses rely on specific conditions
5. Use the Cheatsheet for Payloads — Once you understand the attack, grab quick commands from the matching cheatsheet
6. Document Everything — Screenshot every step for your report

---

Can I use these techniques on any website?

Absolutely not. You must have explicit, written permission to test any system. This means:

• Systems you own personally
• Labs designed for practice (HackTheBox, TryHackMe, PortSwigger Academy)
• Bug bounty programs you've joined through platforms like HackerOne, Bugcrowd, or Intigriti
• Client systems with a signed penetration testing agreement

Testing without permission is illegal and violates the repository's terms of use.

---

Which vulnerability should I focus on first as a beginner?

Priority	Vulnerability	Why
1	IDOR (Insecure Direct Object Reference)	Simple to understand, high impact, teaches you to read API calls
2	Information Disclosure	Teaches you to find hidden endpoints and sensitive data leaks
3	XSS (Cross-Site Scripting)	Common, well-documented, and teaches JavaScript context awareness
4	CSRF (Cross-Site Request Forgery)	Teaches state-changing request analysis
5	SQL Injection	Classic bug that teaches database interaction, but harder to find now

---

Running Tools & Scripts

How do I run the Bug Bounty Automation Workflow?

The bug-bounty-workflow.sh is a bash script that chains together recon, scanning, and reporting:

# Make it executable
chmod +x tools/automation/bug-bounty-workflow.sh

# Run against a target
./tools/automation/bug-bounty-workflow.sh example.com

# With custom output directory
./tools/automation/bug-bounty-workflow.sh example.com -o ./recon-results/

Requirements: The script expects common tools like subfinder, httpx, nuclei, and ffuf to be installed. Check the script header for the complete dependency list.

---

Can I use the GitHub Actions workflow for continuous monitoring?

Yes! The recon-automation.yml workflow can be scheduled to run automatically:

1. Fork this repository
2. Add GitHub Secrets for any API keys required by tools
3. Modify the target list in the workflow file
4. Enable GitHub Actions in your forked repo settings
5. Results will be committed back to your repository on schedule

Refer to the Recon Automation Pipeline: A Deep Dive wiki page for full setup instructions.

---

The Python scripts fail with import errors. What should I do?

Most scripts require specific Python packages. Check the import statements at the top of the script and install missing packages:

# Example for a script importing requests, bs4, and urllib3
pip3 install requests beautifulsoup4 urllib3

If the issue persists, ensure you're using Python 3.6+:

python3 --version

---

How do I use the custom wordlists effectively?

The repository includes three targeted wordlists:

Wordlist	Best Used For	Recommended Tool
custom-subdomains.txt	Subdomain discovery	subfinder, amass, puredns
directories-small.txt	Quick directory scans	ffuf, gobuster, dirsearch
xss-payloads.txt	XSS fuzzing	Burp Intruder, dalfox, kxss

Pro workflow: Start with directories-small.txt for a quick scan. If you find interesting patterns, merge it with larger public wordlists using wordlist-merger.sh and re-scan.

---

Bug Hunting & Reporting

I found a bug! Where do I report it?

The reporting path depends on where you found it:

Discovery Context	Report To
Active Bug Bounty Program	Submit through the program's platform (HackerOne, Bugcrowd, etc.)
No Bug Bounty, But VDP Exists	Follow the organization's Vulnerability Disclosure Program guidelines
No Program Exists	Contact the organization's security team directly via security@ or a contact form
Open Source Project	Report privately to maintainers, or use GitHub's private vulnerability reporting
Found in This Repository	Follow our Security Policy

---

How do I write a good bug report?

Use the built-in template at resources/templates/bug-report-template.md. A good report should include:

1. Clear Title — Vulnerability type + affected endpoint
2. Summary — One paragraph explaining the impact
3. Steps to Reproduce — Numbered, unambiguous instructions
4. Proof of Concept — Screenshots, videos, or code snippets
5. Impact Assessment — What can an attacker actually do?
6. Remediation Guidance — Optional but appreciated

Golden Rule: Write the report so a developer with no security background can understand and fix it in one sitting.

---

What severity rating should I assign?

Use this framework based on CVSS v3.1:

Severity	CVSS Score	Typical Examples
Critical	9.0 - 10.0	Unauthenticated RCE, full database dump, account takeover without user interaction
High	7.0 - 8.9	Stored XSS, SQL Injection with data exfiltration, auth bypass
Medium	4.0 - 6.9	Reflected XSS, CSRF on sensitive actions, open redirect used for phishing
Low	0.1 - 3.9	Clickjacking on non-sensitive pages, missing security headers with minimal impact
Informational	0.0	Missing best practices with no direct exploit path

When in doubt, let the program triage team decide. You can always note your suggested severity with justification.

---

What if the company doesn't have a bug bounty but I still want to report?

1. Check for a VDP — Search for "[company] vulnerability disclosure policy"
2. Be Professional — Send a polite email to security@[company].com explaining what you found
3. Don't Demand Payment — Uninvited pentesting with a ransom demand is extortion, which is illegal
4. Give Time — Allow 90 days for remediation before considering public disclosure
5. Get Confirmation — Ensure they acknowledge receipt before you share sensitive details

---

Contributing & Community

How can I contribute to this repository?

We welcome contributions! Here are the ways:

Contribution Type	Process
New Methodology	Fork → Create your .md file → Submit PR with clear description
New Cheatsheet	Follow the existing format in resources/cheatsheets/ → PR
Bug Fix in a Tool	Open an issue first describing the bug → PR with the fix
New Write-up	Add to write-ups/[year]/ directory → Ensure no sensitive program info is exposed
Documentation Improvement	Typos, clarity fixes, and better examples are always welcome

Always read the full contribution guidelines before submitting.

---

What license is this repository under?

This repository is under the MIT License. See the LICENSE file for full terms.

In short: You can use, modify, and distribute this code freely, even commercially, as long as you include the original license and attribution.

---

How do I join the community?

Connect with the community and repository author:

Platform	Link
Discord	Join the server
YouTube	@awjunaid
Twitter/X	@awjunaid_
LinkedIn	aw-junaid
Instagram	@awjunaid_
Email	awjunaid@proton.me

---

Legal & Ethics

Is using these techniques really legal?

Yes, but only under specific conditions:

• ✅ Testing your own systems
• ✅ Testing a system with a signed, written authorization
• ✅ Participating in a formal bug bounty program (HackerOne, Bugcrowd, Intigriti, etc.)
• ✅ Testing in controlled lab environments (HackTheBox, TryHackMe, PortSwigger Academy)

No exceptions. The Computer Fraud and Abuse Act (CFAA) in the US, the Computer Misuse Act in the UK, and similar laws worldwide carry severe penalties including imprisonment and fines.

---

What happens if I test a website without permission?

You are breaking the law. Potential consequences include:

• Criminal charges under cybercrime legislation
• Civil lawsuits from the affected company
• Permanent ban from bug bounty platforms
• Reputation damage in the security community
• Potential prison time

It is never worth it. The bug bounty community operates on trust and ethics. Even "just looking" at a bug without permission crosses the line. Always get authorization first.

---

Can I keep a copy of sensitive data I find during testing?

No. Once you've confirmed a vulnerability allows data access:

1. Take the absolute minimum amount of data needed for a proof of concept
2. Do not download, store, or share sensitive data beyond what's needed for your report
3. Delete any retrieved data immediately after the report is submitted
4. Never use real user data in public write-ups — always redact

Programs often have strict data handling policies. Violating them can get you removed from the program and potentially face legal action.

---

I have more questions. How do I contact you?

Open an issue on GitHub for repository-related questions, or join the Discord community for real-time discussion. For private or sensitive matters, email awjunaid@proton.me.

---

Still have a question? Check the Wiki Home Page for more topics, or ask in the Discord community — someone has probably asked the same thing before!