01 Bug Bounty Foundations

Welcome to:

Module 01 — Bug Bounty Foundations

Before learning advanced web exploitation techniques, API attacks or automation, you need to understand how professional bug bounty research actually works.

Bug bounty hunting is not:

Find Website
      ↓
Run Tools
      ↓
Try Payloads
      ↓
Submit Anything

Professional security research follows a controlled process:

Program
      ↓
Authorization
      ↓
Scope
      ↓
Rules
      ↓
Target Selection
      ↓
Research
      ↓
Validation
      ↓
Evidence
      ↓
Reporting

This module builds the operational foundation you will use throughout the entire Bug Bounty Hunter learning path.

The most important principle is:

Authorization
Comes Before
Testing

A technically valid vulnerability discovered outside authorized scope can still represent unauthorized activity.

Module Objectives

By the end of this module, you will understand how to:

• explain how bug bounty programs work.

• distinguish public and private programs.

• understand vulnerability disclosure programs.

• understand safe harbor.

• interpret program scope.

• identify in-scope assets.

• identify out-of-scope assets.

• interpret rules of engagement.

• understand prohibited testing.

• understand severity and reward models.

• understand duplicate reports.

• understand program triage.

• understand responsible disclosure.

• protect sensitive data encountered during research.

• select targets strategically.

• create a research methodology.

• establish a repeatable hunting workflow.

• build an attack-surface inventory.

• organize reconnaissance data.

• maintain research notes.

• create evidence registers.

• validate findings safely.

• distinguish observations from vulnerabilities.

• distinguish vulnerabilities from exploitable impact.

• understand proof-of-concept expectations.

• write clear vulnerability titles.

• document reproduction steps.

• understand remediation recommendations.

• communicate professionally with program teams.

• manage rejected and duplicate reports constructively.

• build a professional researcher mindset.

1 — What Is Bug Bounty Hunting?

Bug bounty hunting is:

Authorized
Security Research

performed against systems included within a defined vulnerability disclosure or reward program.

Researchers attempt to identify weaknesses such as:

Authentication Failures

Authorization Failures

Injection

Information Disclosure

Business Logic Abuse

API Security Weaknesses

Session Management Issues

Security Misconfiguration

and report them responsibly.

2 — Why Organizations Run Bug Bounty Programs

Organizations cannot always predict every way their systems may be attacked.

Bug bounty programs provide access to a diverse community of researchers who can evaluate:

Web Applications

APIs

Mobile Applications

Cloud Services

Internet-Facing Assets

from different perspectives.

The model is:

Organization
Defines Scope

      ↓

Researchers
Test Authorized Assets

      ↓

Vulnerabilities
Reported

      ↓

Organization
Validates

      ↓

Issue Remediated

3 — Bug Bounty Program

A bug bounty program usually defines:

Assets

Rules

Testing Restrictions

Vulnerability Categories

Severity

Reward Eligibility

Disclosure Requirements

Your first task is never:

Start Scanning

Your first task is:

Read the Program

4 — Vulnerability Disclosure Program

A Vulnerability Disclosure Program, or:

VDP

provides a formal channel for reporting security weaknesses.

A VDP may:

Allow Security Testing

Define Safe Harbor

Provide Reporting Rules

without necessarily providing:

Financial Rewards

5 — Bug Bounty vs VDP

Bug Bounty

Typically:

Authorized Testing
+
Valid Report
+
Potential Reward

VDP

Typically:

Authorized Disclosure
+
Defined Process

but:

Reward
May Not Exist

Both require responsible behavior.

6 — Public Bug Bounty Program

A public program is generally available to:

Eligible
Security Researchers

without private invitation.

Advantages:

Easy Access

Many Targets

Good Learning Opportunity

Challenges:

High Competition

More Duplicate Reports

Popular Assets
Heavily Tested

7 — Private Bug Bounty Program

Private programs restrict participation to invited researchers.

They may provide:

Lower Competition

Newer Assets

Different Scope

Higher-Value Targets

Researchers may receive invitations based on:

Report Quality

Reputation

Historical Performance

Specialized Skills

8 — Program Scope

Scope defines:

What You
Are Authorized
to Test

Example:

In Scope:

app.example.com

api.example.com

*.staging.example.com

This does not automatically mean:

Every System
Owned by
the Company

is authorized.

9 — In-Scope Assets

In-scope assets might include:

Domains

Subdomains

API Endpoints

Mobile Applications

Specific IP Addresses

Specific Products

Always document them.

10 — Out-of-Scope Assets

A program may explicitly exclude:

Third-Party Services

Employee Systems

Production Infrastructure

Acquired Companies

Partner Domains

Support Platforms

Do not test them.

11 — Scope Ambiguity

Suppose scope states:

*.example.com

but you discover:

partner.example.net

Do not assume authorization.

The professional approach is:

Unclear Scope
      ↓
Stop
      ↓
Verify Program Rules

12 — Authorization Boundary

Always remember:

Discovering
an Asset
      ≠
Authorization
to Test It

Reconnaissance may discover systems outside the intended program boundary.

Mark them:

Out of Scope

Unknown Scope

Needs Verification

13 — Rules of Engagement

Rules of engagement describe:

How
You May Test

They may include restrictions around:

Scanning

Automation

Authentication

Data Access

User Interaction

Rate Limits

Denial of Service

Social Engineering

14 — Prohibited Activities

Programs often prohibit activities such as:

Denial of Service

Destructive Testing

Social Engineering

Physical Attacks

Spam

Data Destruction

Excessive Automation

Testing Other Users'
Accounts

The exact rules vary by program.

15 — Safe Harbor

Safe harbor provides assurances for researchers who:

Act in Good Faith

Follow Scope

Follow Rules

Report Responsibly

Safe harbor is not permission to ignore program restrictions.

16 — Good-Faith Research

Good-faith research means:

Test Only
What Is Necessary

      ↓

Minimize Impact

      ↓

Protect Data

      ↓

Report Promptly

17 — Minimum Necessary Testing

Suppose you discover an authorization issue.

You do not need to:

Download
Every Customer Record

to prove impact.

You may only need to demonstrate:

User A
Can Access
User B's Resource

using controlled test accounts where possible.

18 — Protecting User Data

If you accidentally encounter sensitive information:

Stop

Minimize Access

Do Not Copy
Unnecessarily

Document Carefully

Report

Do not use the vulnerability to explore unrelated user data.

19 — Test Accounts

Whenever possible, use:

Researcher-Controlled
Accounts

Example:

Account A

Account B

This is especially useful for:

IDOR

Authorization

Account Recovery

Sharing

Role Testing

20 — Two-Account Methodology

For authorization testing:

Account A
Creates Resource
      ↓
Capture Resource ID
      ↓
Account B
Attempts Access
      ↓
Compare Authorization

This is safer than testing against real users.

21 — Program Severity

Programs often classify findings as:

Critical

High

Medium

Low

Informational

Severity depends on:

Exploitability

Impact

Required Access

Affected Users

Business Context

22 — Severity Is Not Just Vulnerability Name

Example:

IDOR

could expose:

Public Profile Picture

or:

Financial Records

The vulnerability category may be similar.

The impact is very different.

23 — Impact

Impact asks:

What Can
an Attacker
Actually Achieve?

Examples:

Read Sensitive Data

Modify Another User's Data

Take Over Account

Perform Unauthorized Action

Escalate Privileges

Execute Code

24 — Exploitability

Exploitability considers:

Authentication Required?

Special Role Required?

User Interaction Required?

Complex Race Condition?

Predictable Identifier?

Repeatable Attack?

25 — Vulnerability vs Security Observation

Not every unusual behavior is a vulnerability.

Example:

Server Reveals
Software Version

may be an observation.

It becomes more meaningful if:

Version Is Vulnerable

and

Attack Is
Actually Possible

26 — Vulnerability Validation

Before reporting:

Reproduce

      ↓

Confirm

      ↓

Understand

      ↓

Determine Impact

Avoid submitting findings that you have not verified.

27 — Reproducibility

A good vulnerability should ideally be:

Repeatable

Document:

Request

Response

User State

Required Role

Application State

28 — False Positive

A false positive occurs when something initially appears vulnerable but further testing shows:

Security Control
Is Working

Example:

Modified Resource ID
Returns Data

but the returned data is intentionally public.

29 — Duplicate Report

A duplicate occurs when another researcher already submitted substantially the same issue.

This is common.

It does not necessarily mean:

Your Research
Was Poor

It may simply mean:

Someone Found
It Earlier

30 — Reducing Duplicates

You cannot eliminate duplicates entirely.

But you can improve your chances by:

Exploring Less Obvious
Functionality

Testing New Features

Testing Complex
Business Logic

Developing Deep
Target Knowledge

31 — Program Triage

After submission, a program may:

Review Report

Reproduce Finding

Request Information

Assign Severity

Mark Duplicate

Reject

Accept

32 — Triage Questions

Triage teams often ask:

Can We Reproduce It?

Is the Asset
In Scope?

Is This Intended?

What Is the Impact?

Does It Require
Special Conditions?

Has It Already
Been Reported?

33 — Researcher Communication

Professional communication should be:

Clear

Technical

Concise

Evidence-Based

Respectful

Avoid:

Threatening Language

Emotional Arguments

Exaggerated Impact

Repeated Demands

34 — Rejected Reports

A rejected report can still teach you something.

Ask:

Was the Asset
Out of Scope?

Was Behavior
Intended?

Was Impact Missing?

Were Reproduction
Steps Unclear?

Was It a Duplicate?

Use the feedback to improve.

35 — Target Selection

One of the most important research skills is:

Choosing
What to Test

A large program may contain:

Hundreds of
Assets

You cannot test everything equally.

36 — Target Selection Factors

Consider:

Scope Size

Application Complexity

Feature Richness

Recent Changes

Authentication

APIs

Multiple User Roles

Business Workflows

Competition

37 — High-Value Features

Interesting areas often include:

Authentication

Account Recovery

User Profiles

Payments

Subscriptions

File Uploads

Sharing

Admin Features

APIs

Integrations

Webhooks

38 — Understand Before Attacking

Before testing:

Use the
Application
Normally

Understand:

What Does It Do?

Who Uses It?

What Roles Exist?

What Data Exists?

Which Workflows Matter?

39 — Application Mapping

Create an application map.

Example:

Authentication
│
├── Registration
├── Login
├── MFA
└── Password Reset

Account
│
├── Profile
├── Settings
└── Delete Account

Payments
│
├── Add Card
├── Purchase
├── Refund
└── Subscription

This becomes your:

Testing Map

40 — Feature Inventory

Create:

Feature_Inventory.csv

with:

Feature	Authentication	Role	Inputs	API	Priority

41 — Attack Surface

Attack surface means:

Everything
an Attacker
Can Interact With

Examples:

Pages

Endpoints

Parameters

Headers

Cookies

Files

APIs

WebSockets

Mobile APIs

42 — External Attack Surface

External attack surface might include:

Domains

Subdomains

IP Addresses

Cloud Services

API Hosts

CDNs

Storage

43 — Application Attack Surface

Inside one application:

Routes

Features

Parameters

Objects

Roles

Workflows

form the application attack surface.

44 — Reconnaissance

Reconnaissance helps answer:

What Exists?

It may include:

Asset Discovery

Technology Identification

Endpoint Discovery

JavaScript Review

Content Discovery

Later modules will cover recon in much more depth.

45 — Passive Recon

Passive reconnaissance attempts to gather information without directly interacting heavily with the target.

Examples:

Public DNS Information

Certificate Data

Search Engines

Public Repositories

Public Documentation

46 — Active Recon

Active reconnaissance interacts directly with authorized targets.

Examples:

HTTP Requests

Port Checks

Content Discovery

Endpoint Enumeration

Only perform active reconnaissance where permitted.

47 — Reconnaissance Does Not Equal Exploitation

Recon answers:

What Exists?

Testing answers:

Is It Vulnerable?

Keep these phases organized.

48 — Research Workflow

A professional workflow might look like:

Read Program
      ↓
Record Scope
      ↓
Choose Target
      ↓
Understand Application
      ↓
Map Features
      ↓
Recon
      ↓
Create Hypotheses
      ↓
Test
      ↓
Validate
      ↓
Document
      ↓
Report

49 — Hypothesis-Driven Hunting

Instead of:

Try Every
Payload Everywhere

build hypotheses.

Example:

Users Can
Create Projects

Projects Have
Numeric IDs

Maybe Authorization
Is Based Only
on the ID

Now test:

Can User B
Access User A's
Project?

50 — Why Hypotheses Matter

Hypothesis-driven testing reduces:

Randomness

Noise

Tool Dependence

and improves:

Reasoning

Coverage

Depth

51 — Research Question

For each feature ask:

Who Can
Perform This Action?

What Object
Is Being Accessed?

What Input
Can Be Controlled?

What Validation
Occurs?

What Authorization
Occurs?

52 — Authentication Questions

For login and authentication:

Can Accounts
Be Enumerated?

Are Rate Limits
Present?

How Does MFA Work?

How Are Sessions
Created?

How Does
Password Reset Work?

53 — Authorization Questions

Ask:

Can User A
Access User B?

Can Low Privilege
Access Admin Function?

Can Object IDs
Be Modified?

Does the API
Recheck Authorization?

54 — Input Questions

For each parameter:

What Type
Is Expected?

Can the Value
Be Modified?

Where Is
It Used?

Does It Reach
Backend Systems?

55 — Business Logic Questions

Ask:

Can Steps
Be Skipped?

Can Workflow
Order Change?

Can Values
Be Reused?

Can Limits
Be Bypassed?

Can Actions
Be Repeated?

56 — Client vs Server Trust

Never assume the application trusts only server-side values.

Test whether security depends on:

Hidden Fields

JavaScript

Disabled Buttons

Client Validation

UI Restrictions

A fundamental principle:

Client-Side
Restriction
      ≠
Security Boundary

57 — HTTP Understanding

Web security research depends heavily on understanding:

Request
      ↓
Server
      ↓
Response

A request may contain:

Method

Path

Headers

Cookies

Parameters

Body

58 — Request Comparison

One powerful technique is comparing requests.

Example:

User A Request

vs

User B Request

Ask:

What Changed?

User ID?

Cookie?

Token?

Object ID?

Role?

59 — Baseline Request

Before modifying anything:

Capture
Normal Request

This gives you a known-good baseline.

Then change:

One Variable
at a Time

where practical.

60 — Research Notes

Maintain notes from the beginning.

Do not rely on:

Memory

after hours of testing.

61 — Research Notebook

Create:

Research_Notebook.md

with:

# Program

# Scope

# Target

# Accounts

# Technologies

# Features

# Endpoints

# Parameters

# Hypotheses

# Tests

# Findings

# Evidence

# Reports

62 — Scope Register

Create:

Scope_Register.csv

with:

Asset	Type	Scope Status	Testing Restrictions	Notes

63 — Endpoint Register

Create:

Endpoint_Register.csv

with:

Endpoint	Method	Authentication	Parameters	Function

64 — Parameter Register

Create:

Parameter_Register.csv

with:

Parameter	Endpoint	Type	User Controlled	Tested

65 — Hypothesis Register

Create:

Research_Hypotheses.csv

with:

ID	Feature	Hypothesis	Test	Result	Status

66 — Evidence Register

Create:

Evidence_Register.csv

with:

Evidence ID	Finding	Artifact	Purpose

67 — Vulnerability Candidate Register

Maintain:

Vulnerability_Candidates.csv

with:

Candidate	Feature	Evidence	Impact	Status

Statuses might include:

Investigating

Confirmed

Not Vulnerable

Duplicate Suspected

Reported

68 — Keep Notes Reproducible

Weak note:

IDOR works

Better:

Account A created
invoice ID 8472.

Account B sent
GET /api/invoices/8472.

Server returned
Account A's invoice
without authorization
failure.

69 — Evidence Quality

Good evidence should demonstrate:

Action

Result

Unauthorized Impact

Not merely:

Tool Says
Vulnerable

70 — Screenshots

Screenshots are useful for:

Visual Impact

Application State

Successful Exploitation

but they should complement:

Technical
Reproduction Steps

71 — HTTP Evidence

For web findings, useful evidence often includes:

Request

Response

Affected Parameter

Authenticated Role

Object Ownership

72 — Minimize Sensitive Evidence

If a response contains sensitive information:

Capture Only
What Is Necessary

Redact unrelated personal data where appropriate.

73 — Proof of Concept

A proof of concept demonstrates:

The Vulnerability
Is Real

A PoC should be:

Minimal

Controlled

Reproducible

Non-Destructive

74 — Do Not Over-Exploit

Once the vulnerability and impact are established:

Stop

Do not continue exploitation merely to see:

How Far
You Can Go

unless explicitly required and allowed.

75 — Vulnerability Report

A professional report usually contains:

Title

Summary

Affected Asset

Prerequisites

Steps to Reproduce

Evidence

Impact

Severity

Remediation

76 — Report Title

Weak:

Security Bug

Better:

IDOR Allows
Authenticated Users
to Access Other
Users' Invoices

The title should explain:

Vulnerability
+
Impact

77 — Summary

Your summary should explain:

What Is Wrong

Where

Who Can Exploit It

What Happens

78 — Steps to Reproduce

Reproduction steps should be:

Numbered

Specific

Repeatable

Another security engineer should be able to reproduce the finding.

79 — Example Structure

1. Authenticate as User A.

2. Create a new invoice.

3. Record invoice ID.

4. Authenticate as User B.

5. Request User A's
   invoice ID.

6. Observe that the
   server returns
   User A's invoice.

80 — Impact Statement

Weak:

This Is Dangerous

Better:

Any authenticated user
can access invoice records
belonging to other customers,
potentially exposing names,
addresses and billing data.

Impact should be:

Specific

Supported

Realistic

81 — Avoid Impact Inflation

Do not claim:

Full Company
Compromise

when you proved only:

One Unauthorized
Record Access

Professional reports do not need exaggerated language.

82 — Remediation

Where appropriate, suggest:

Authorization Checks

Server-Side Validation

Ownership Validation

Role Validation

But remember:

You May Not
Know the Entire
Application Architecture

Keep remediation recommendations technically reasonable.

83 — Report Submission

Before submitting:

Confirm Scope

Reproduce Again

Remove Test Data

Review Evidence

Check Report Clarity

84 — Duplicate Handling

If triage responds:

Duplicate

record:

Program

Target

Vulnerability Type

What You Learned

Then continue.

85 — Informational Findings

Programs may classify some reports:

Informational

This often means:

Behavior Exists

but

Security Impact
Is Insufficient

Use this feedback to improve impact analysis.

86 — Not Applicable

A report may be marked:

Not Applicable

if:

No Security Impact

Expected Behavior

Out of Scope

Cannot Reproduce

Review the reason carefully.

87 — Researcher Reputation

Long-term reputation comes from:

Accurate Findings

Clear Reports

Respectful Communication

Low False-Positive Rate

Responsible Testing

not from:

Report Volume
Alone

88 — Quality vs Quantity

Ten weak reports may be less valuable than:

One Well-Validated
High-Quality Finding

Focus on:

Depth

as your skills improve.

89 — Target Familiarity

Researchers often gain an advantage by repeatedly studying:

One Application

One Company

One Technology Stack

because they understand:

Features

Roles

Historical Behavior

Attack Surface

better than someone scanning randomly.

90 — Change-Based Hunting

New functionality may introduce vulnerabilities.

Look for:

New Features

New APIs

New Subdomains

New Mobile Releases

New Integrations

because new code may have:

Less Security
Testing History

91 — Feature-Based Hunting

Instead of hunting:

XSS
Everywhere

you might focus on:

File Sharing

and ask:

Can Unauthorized Users
Access Shared Files?

Can Expired Links
Still Work?

Can Permissions
Be Modified?

Can Files
Be Replaced?

92 — Vulnerability-Class Hunting

You can also focus on one category such as:

Authorization

and deeply test it across:

Web

API

Mobile

Admin

Integrations

93 — Role-Based Hunting

Create:

User

Premium User

Support Agent

Administrator

where authorized.

Compare:

What Each Role
Can Do

Role boundaries frequently reveal:

Access Control
Vulnerabilities

94 — State-Based Testing

Applications change state.

Example:

Invite Created

Invite Accepted

Invite Revoked

Account Deleted

Test security behavior at each state.

95 — Workflow Testing

Example workflow:

Create Order
      ↓
Pay
      ↓
Ship
      ↓
Refund

Ask:

Can Payment
Be Skipped?

Can Refund
Be Repeated?

Can Quantity
Become Negative?

Can Completed
State Be Changed?

96 — Research Methodology

Use:

Understand

      ↓

Map

      ↓

Hypothesize

      ↓

Test

      ↓

Observe

      ↓

Pivot

      ↓

Validate

      ↓

Report

97 — Avoid Tool-Driven Hunting

Weak workflow:

Run Tool
      ↓
Read Findings
      ↓
Submit

Better:

Understand Feature
      ↓
Identify Trust Boundary
      ↓
Form Hypothesis
      ↓
Use Tool
Where Helpful
      ↓
Validate Manually

98 — Tools Are Assistants

Tools can help with:

Proxying

Recon

Enumeration

Request Editing

Automation

Data Organization

but:

Tool Output
      ≠
Confirmed Vulnerability

99 — Tool Noise

Automated tools may generate:

False Positives

Duplicate Results

Irrelevant Findings

Out-of-Scope Traffic

You remain responsible for validating results.

100 — Researcher Decision Model

Use:

Observation
      ↓
Question
      ↓
Hypothesis
      ↓
Test
      ↓
Evidence
      ↓
Impact
      ↓
Finding

not:

Scanner Alert
      ↓
Bug Report

101 — Ethical Escalation

Suppose testing unexpectedly reveals:

Serious
Production Impact

or:

Sensitive User Data

The professional response is:

Stop

Preserve Minimal Evidence

Notify Program

not:

Continue Exploring

102 — Handling Accidental Impact

If your authorized test causes unexpected behavior:

Stop Testing

Document What Happened

Notify Program

Follow Instructions

Transparency matters.

103 — Research Environment

Maintain a dedicated research environment where practical.

Separate:

Personal Activity

Research Accounts

Testing Notes

Security Tools

This improves organization and reduces mistakes.

104 — Account Naming

Where allowed, clearly identify research accounts.

Example:

researcher-test-a

researcher-test-b

This can simplify authorization testing and cleanup.

105 — Data Hygiene

Do not leave unnecessary:

Test Files

Test Accounts

API Keys

Public Resources

after research if cleanup is permitted and appropriate.

106 — Documentation Discipline

At the end of every research session, update:

Scope

Assets

Endpoints

Hypotheses

Findings

Next Actions

This makes future sessions much more productive.

107 — Daily Research Workflow

A simple daily workflow:

Review Notes
      ↓
Select Feature
      ↓
Define Hypotheses
      ↓
Test
      ↓
Document
      ↓
Review Findings
      ↓
Plan Next Session

108 — Research Backlog

Create:

Research_Backlog.csv

with:

Priority	Target	Feature	Hypothesis	Status

109 — Prioritization

Prioritize features based on:

Security Impact

Complexity

User Roles

Sensitive Data

Business Importance

New Functionality

110 — Don’t Chase Only Critical Bugs

High-impact vulnerabilities are valuable.

But learning to find:

Medium

Low

Informational

issues can improve your understanding of the application.

The important skill is:

Correct
Assessment

111 — Researcher Feedback Loop

Your development should follow:

Test
      ↓
Report
      ↓
Triage Feedback
      ↓
Learn
      ↓
Improve Methodology
      ↓
Test Again

112 — Build Pattern Recognition

Over time you may notice patterns:

New API
Missing Authorization

Legacy Feature
Weak Validation

Mobile API
Different Controls

Admin Feature
Trusts Client Input

Pattern recognition becomes a major researcher advantage.

113 — Learn From Valid Reports

For every accepted report, record:

Why You
Found It

Which Hypothesis
Worked

Which Evidence
Was Strong

What Triage
Valued

114 — Learn From Rejections

For every rejected report, record:

Why It Failed

Was Impact Weak?

Was It Intended?

Was Scope Wrong?

Was Evidence Poor?

Was It Duplicate?

115 — Research Metrics

Useful personal metrics might include:

Hours Researched

Features Tested

Hypotheses Tested

Valid Findings

Duplicate Findings

Rejected Findings

But avoid judging progress only by:

Bounty Amount

116 — Skill Development

Your real progress is:

Better Questions

Better Methodology

Better Evidence

Better Reports

Better Impact Analysis

Practical Exercise 1 — Analyze Program Scope

Create a fictional program with:

5 In-Scope Assets

3 Out-of-Scope Assets

Testing Restrictions

Safe Harbor

Then explain what you are authorized to test.

Practical Exercise 2 — Build Scope Register

Create:

Scope_Register.csv

and classify:

In Scope

Out of Scope

Unknown

assets.

Practical Exercise 3 — Create Two Research Accounts

In an authorized training application, create:

User A

User B

Document:

Account ID

Role

Accessible Features

Do not store real passwords in your report.

Practical Exercise 4 — Map an Application

Select an authorized lab application.

Build:

Application_Map.md

covering:

Authentication

Account

Profile

Files

Payments

API

Admin

where applicable.

Practical Exercise 5 — Build Feature Inventory

Create at least:

20 Features

and classify them by:

Role

Authentication

Input

Sensitivity

Testing Priority

Practical Exercise 6 — Create Hypotheses

Create at least:

15 Security
Hypotheses

such as:

Can User B
Access User A's File?

Can a Revoked
Invite Still Work?

Can a Price
Be Modified?

Can an API
Endpoint Be Called
Without the UI?

Practical Exercise 7 — Build Endpoint Register

Document:

10 Application
Endpoints

with:

Method

Authentication

Parameters

Function

Practical Exercise 8 — Evidence Practice

Take a fictional access-control finding.

Create:

Evidence_Register.csv

with:

Baseline Request

Modified Request

Response

Impact

Practical Exercise 9 — Write a Vulnerability Report

Create:

Vulnerability_Report.md

containing:

Title

Summary

Asset

Prerequisites

Steps

Evidence

Impact

Remediation

Practical Exercise 10 — Analyze a Rejected Report

Scenario:

A researcher reports:

Server
Discloses Version

but provides no exploitable impact.

Explain why this could be:

Informational

or

Not Applicable

and what additional evidence would be required to establish meaningful risk.

Practical Exercise 11 — Research Backlog

Create:

Research_Backlog.csv

for:

Authentication

Authorization

Files

Payments

API

Account Recovery

Prioritize each area.

Practical Exercise 12 — Build Your Methodology

Create:

Bug_Bounty_Methodology.md

using:

Program Review
      ↓
Scope
      ↓
Target Selection
      ↓
Application Mapping
      ↓
Recon
      ↓
Hypotheses
      ↓
Testing
      ↓
Validation
      ↓
Evidence
      ↓
Reporting

Knowledge Check

1. What is bug bounty hunting?

2. What is a vulnerability disclosure program?

3. How does a public program differ from a private program?

4. What is program scope?

5. What is an in-scope asset?

6. What is an out-of-scope asset?

7. Why does discovering an asset not authorize testing?

8. What are rules of engagement?

9. What is safe harbor?

10. What does good-faith research mean?

11. Why should researchers minimize data access?

12. Why are researcher-controlled accounts useful?

13. What is the two-account methodology?

14. What factors influence vulnerability severity?

15. Why is vulnerability name alone insufficient for severity?

16. What is security impact?

17. What is exploitability?

18. What is a false positive?

19. What is a duplicate report?

20. Why are duplicates common?

21. How can deep target knowledge reduce duplicates?

22. What does a triage team do?

23. What makes researcher communication professional?

24. What can be learned from rejected reports?

25. What factors help with target selection?

26. What is application mapping?

27. What is attack surface?

28. What is passive reconnaissance?

29. What is active reconnaissance?

30. Why must active reconnaissance follow program rules?

31. What is hypothesis-driven hunting?

32. Why is it better than random payload testing?

33. What questions should be asked about authentication?

34. What questions should be asked about authorization?

35. What questions help identify business-logic weaknesses?

36. Why are client-side restrictions not security boundaries?

37. Why should normal requests be captured before modification?

38. Why are research notes important?

39. What should a research notebook contain?

40. What is a hypothesis register?

41. What makes vulnerability evidence strong?

42. What is a proof of concept?

43. Why should exploitation stop once impact is established?

44. What should a vulnerability report contain?

45. What makes a good vulnerability title?

46. What makes reproduction steps effective?

47. Why should impact not be exaggerated?

48. Why are tools not sufficient to prove a vulnerability?

49. How should accidental impact be handled?

50. What should researchers learn from triage feedback?

Key Takeaways

Professional bug bounty research begins with:

Authorization
      ↓
Scope
      ↓
Rules

before:

Testing

The research methodology is:

Understand
      ↓
Map
      ↓
Hypothesize
      ↓
Test
      ↓
Validate
      ↓
Document
      ↓
Report

Remember:

Asset Discovered
      ≠
Authorized Target

Tool Finding
      ≠
Confirmed Vulnerability

Interesting Behavior
      ≠
Security Impact

Technical Vulnerability
      ≠
Critical Severity

Proof of Concept
      ≠
Permission to
Over-Exploit

A strong bug bounty hunter develops:

Technical Skill

      +

Methodology

      +

Evidence

      +

Judgment

      +

Communication

Career Connection

These foundations are valuable for:

Bug Bounty Hunters

Security Researchers

Application Security Analysts

Web Penetration Testers

API Security Testers

Junior AppSec Engineers

During interviews, you should be able to explain:

How You
Interpret Scope

How You
Build an
Attack Surface

How You
Create Testing
Hypotheses

How You
Validate Findings

How You
Collect Evidence

How You
Determine Impact

How You
Write Reports

Instead of saying:

I Run
Security Tools

you should be able to explain:

I begin by
reviewing authorization,
scope and testing rules.

I map the target's
features, roles and
attack surface.

I create security
hypotheses, test them
methodically and validate
findings with controlled
evidence.

I minimize impact,
document reproducible
steps and communicate
the realistic security
impact through a
professional report.

What’s Next?

➡️ Next: 02 — Web Security

You now understand:

Programs

Scope

Authorization

Methodology

Evidence

Reporting

The next step is to build the technical foundation required to investigate:

Web Applications

In the next module, you will learn how modern web applications work and how to evaluate:

HTTP

Requests and Responses

Authentication

Sessions

Cookies

Authorization

Access Control

Input Handling

XSS

SQL Injection

CSRF

SSRF

File Uploads

Path Traversal

Information Disclosure

Business Logic

You will move from:

I Know
How Bug Bounty
Programs Work

to:

I Can
Systematically Assess
a Web Application

using:

Application Mapping
      ↓
HTTP Analysis
      ↓
Authentication Testing
      ↓
Authorization Testing
      ↓
Input Testing
      ↓
Business Logic Testing
      ↓
Validation
      ↓
Reporting

➡️ Next: 02 — Web Security