Most Bug Bounty Hunters Start Testing Too Early

You find a bug bounty program.

You see:

example.com

And immediately start:

nmap
directory fuzzing
parameter testing
XSS payloads
SQL injection

That’s understandable.

It’s also one of the easiest ways to waste your time.

Because:

The domain you were given is rarely the entire attack surface.

A company might have:

example.com
www.example.com
api.example.com
dev.example.com
staging.example.com
portal.example.com
cdn.example.com
old.example.com
mobile.example.com

And those may connect to:

• Different applications
• Different technologies
• Different teams
• Different cloud infrastructure
• Different authentication systems
• Different APIs
• Different deployment pipelines

Your first job isn’t:

“Find a vulnerability.”

Your first job is:

Understand what exists.

What Is Reconnaissance?

Reconnaissance, or recon, is the process of gathering information about a target before deeper security testing.

In bug bounty hunting, recon can help answer:

What assets belong to the organization?

Which ones are actually in scope?

Which hosts are alive?

What technologies are running?

Which applications are public?

Where are APIs exposed?

What changed recently?

Which assets deserve manual investigation?

Think of it as:

Building the map before looking for weaknesses.

Recon ≠ Hacking

Recon itself can be passive or active.

Passive recon

You gather information from existing sources without directly probing the target infrastructure.

Examples:

• Certificate transparency
• Public DNS information
• Search engines
• Public code repositories
• Archived URLs
• Public documentation
• Public datasets

Active recon

You directly interact with target infrastructure.

Examples:

• DNS queries
• HTTP requests
• Port/service discovery
• Crawling
• Content discovery

The distinction matters because:

A bug bounty’s rules may allow some activities and prohibit others.

Always read the program policy before touching the target.

The First Rule: Read the Scope

Before running a single command:

Read the bounty program’s scope.

Look for:

• In-scope domains
• In-scope applications
• Out-of-scope assets
• Testing restrictions
• Rate limits
• Prohibited techniques
• Authentication requirements
• Third-party infrastructure rules
• Disclosure requirements

A security researcher can discover a technically interesting host and still be testing the wrong target.

Scope Is Your Legal Boundary

Suppose the program says:

*.example.com

That may include:

api.example.com
portal.example.com
dev.example.com

But don’t automatically assume:

example-company-partner.com

is included just because the company uses it.

Ownership and authorization are different questions.

Build a Scope File

Before recon, create something like:

scope/
├── in-scope.txt
├── out-of-scope.txt
├── exclusions.txt
└── notes.txt

Then record:

• Exact domains
• Wildcards
• IP ranges
• Applications
• Restrictions

This sounds boring.

It prevents mistakes.

Phase 1: Start With the Organization

Don’t immediately start with:

example.com

Start with:

Who owns example.com?

Learn:

• Official domains
• Brand names
• Subsidiaries
• Acquisitions
• Country domains
• Developer portals
• Public infrastructure references

This is where OSINT becomes useful.

Think in Terms of an Organization Graph

Instead of:

example.com

think:

Company
 ├── Main website
 ├── API
 ├── Mobile apps
 ├── Developer portal
 ├── Cloud infrastructure
 ├── Documentation
 ├── Support systems
 ├── Old properties
 └── Acquired products

The goal is to discover relationships.

Phase 2: Domain Discovery

Now identify domains and subdomains associated with the authorized target.

Useful sources can include:

Certificate Transparency

Certificate Transparency logs can reveal hostnames included in publicly issued TLS certificates.

One commonly used source is:

crt.sh

For example, researchers can search for certificates associated with an authorized domain and extract hostnames for further validation.

DNS Is Another Major Source

DNS can reveal relationships involving:

• A records
• AAAA records
• CNAME records
• MX records
• NS records
• TXT records

You aren’t necessarily looking for a vulnerability yet.

You’re asking:

What infrastructure exists?

Subdomain Enumeration

Subdomain discovery can reveal:

api.example.com
dev.example.com
staging.example.com
admin.example.com
support.example.com
docs.example.com

But remember:

A discovered hostname is not automatically in scope.

Validate it against the bounty program.

Why Subdomains Matter

Different subdomains often represent different applications.

For example:

www.example.com

might be a marketing site.

While:

api.example.com

might expose an API.

And:

portal.example.com

might contain an authenticated application.

Same organization.

Completely different attack surfaces.

Phase 3: Find Live Hosts

A discovered hostname isn’t necessarily active.

It might be:

Offline.

Parked.

Redirected.

Internal-only.

Historical.

Misconfigured.

So the next step is determining:

Which assets currently respond?

This creates a useful pipeline:

Discovered
    ↓
Resolved
    ↓
Responding
    ↓
Interesting

Don’t Treat Every Open Port as a Vulnerability

This is a common beginner mistake.

You find:

Port 443 open.

That’s normal.

You find:

Port 22 open.

Still not automatically a vulnerability.

You find:

Port 8080 open.

Interesting.

But:

Interesting ≠ vulnerable.

Recon tells you where to investigate.

It doesn’t prove a security issue.

Technology Fingerprinting

Once you find a live web application, identify its technology stack.

Look for:

• Web server
• Framework
• CMS
• JavaScript libraries
• CDN
• WAF
• Hosting provider
• API technology

Tools can help automate this.

One commonly used technology profiler is:

Wappalyzer

The goal isn’t to blindly attack every detected technology.

It’s to understand:

What you’re looking at.

Technology Fingerprinting Changes Your Strategy

Imagine you discover:

Frontend: React
Backend: Node.js
API: REST
CDN: Cloudflare
Auth: OAuth

That’s very different from:

WordPress
Apache
PHP
MySQL

The technology stack determines:

What kinds of security questions are worth asking.

Phase 4: Look at JavaScript

Modern web applications often expose enormous amounts of functionality through JavaScript.

A homepage may load:

app.js
runtime.js
vendor.js
chunk-123.js

These files can reveal:

• API endpoints
• Routes
• Feature flags
• Parameter names
• Third-party services
• Environment references
• Client-side logic

JavaScript Is Often a Map of the Application

Imagine the HTML only shows:

Login

Dashboard

Profile

But JavaScript references:

/api/v1/users
/api/v1/orders
/api/v1/export
/api/v1/admin

Now you know the application has additional functionality.

You haven’t exploited anything.

You’ve simply discovered:

The application’s own map.

Search JavaScript for URLs

A basic recon workflow can extract:

• Absolute URLs
• Relative API paths
• WebSocket endpoints
• External services

Then organize them.

For example:

API
 ├── /api/users
 ├── /api/orders
 ├── /api/profile
 └── /api/settings

Now manual testing becomes much more targeted.

Look for API Documentation

Modern applications may expose:

• Swagger/OpenAPI
• GraphQL documentation
• Developer portals
• API reference pages

These can be extremely valuable for understanding:

How the application is supposed to work.

A documented API can reveal:

• Endpoints
• Parameters
• Authentication requirements
• Object relationships
• HTTP methods

GraphQL Deserves Special Attention

If the application uses GraphQL, identify:

GraphQL endpoint

Queries

Mutations

Objects

Authentication behavior

Don’t immediately attempt aggressive exploitation.

First understand:

What the API exposes.

Phase 5: Look at Historical Data

One of the most overlooked recon sources is:

The past.

Websites change.

But old URLs can remain discoverable.

Wayback Machine

can help researchers understand historical versions of authorized websites.

You might discover:

old.example.com
beta.example.com
legacy.example.com
api-v1.example.com

The important question becomes:

Does any of this still exist?

Historical Doesn’t Mean In Scope

An archived URL doesn’t automatically authorize testing.

Use historical data for:

Discovery.

Then verify:

Current ownership.

Current availability.

Current bounty scope.

Phase 6: Search Engines Are Recon Tools

Search engines index enormous amounts of information.

For authorized targets, search can help discover:

• Public documentation
• Login pages
• Developer portals
• Forgotten subdomains
• Public files
• Error pages
• Technology references

Search operators can narrow results.

For example:

site:example.com

can focus results on a domain.

Search for the Organization’s Developers

Public repositories can reveal architecture information.

Look at:

• GitHub
• GitLab
• Bitbucket
• Public package registries
• Documentation sites

But remember:

Public code does not mean permission to attack associated infrastructure.

Use it as intelligence about the authorized target.

GitHub Can Reveal Application Clues

Developers may publish:

• API documentation
• Frontend source
• SDKs
• Configuration examples
• Environment variable names
• Endpoint references

Researchers should be particularly alert to accidentally exposed credentials.

If you discover an actual secret:

Don’t use it.

Don’t test whether it works by logging into an unrelated system.

Follow the program’s vulnerability-reporting policy.

Search for Secrets Responsibly

The goal of bug bounty recon is not:

“How many credentials can I steal?”

It’s:

“Can I safely demonstrate a security impact within scope?”

If a credential appears exposed:

• Don’t access unrelated accounts.
• Don’t download unnecessary data.
• Don’t pivot into unrelated infrastructure.
• Report the exposure according to program rules.

Phase 7: Cloud Infrastructure

Modern companies frequently use:

• AWS
• Azure
• Google Cloud
• Cloudflare
• Vercel
• Netlify
• Other SaaS/cloud platforms

Recon can reveal references to these services.

Look for:

• DNS records
• Public documentation
• JavaScript
• Certificate information
• Public repositories

But:

Never assume a cloud resource is yours to test simply because it appears related to the company.

Ownership and bounty scope must be established.

Phase 8: Identify Forgotten Assets

This is where recon becomes interesting.

Companies accumulate infrastructure.

They launch:

Campaigns.

Beta applications.

Temporary portals.

Development environments.

Regional services.

Some eventually become forgotten.

Potentially interesting patterns include:

dev.example.com
staging.example.com
beta.example.com
old.example.com
test.example.com
legacy.example.com

These names are clues.

Not proof of vulnerability.

The Goal Isn’t to Find “dev.example.com”

The goal is to determine:

What is running there?

Maybe:

Nothing.

Maybe:

A redirect.

Maybe:

A test application.

Maybe:

An abandoned service.

Maybe:

A production application.

Recon converts:

Unknown

into:

Known.

Phase 9: Map the Attack Surface

At this point, build a table.

Now you have something far more useful than:

“I found 500 subdomains.”

Recon Should Produce Intelligence, Not Noise

Beginners often celebrate:

10,000 URLs

2,000 subdomains

50,000 endpoints

But volume isn’t the goal.

The goal is:

Useful attack-surface knowledge.

Ten carefully understood assets can be more valuable than 10,000 random URLs.

Phase 10: Prioritize

Not every asset deserves equal attention.

Create a priority system.

High priority

• Authentication systems
• APIs
• Admin functionality
• Sensitive applications
• Newly discovered assets
• Assets with unusual behavior

Medium priority

• Customer-facing applications
• Developer portals
• Business applications

Lower priority

• Static marketing pages
• CDN assets
• Simple informational pages

This isn’t a vulnerability ranking.

It’s:

A research-effort ranking.

Think Like a Bug Bounty Hunter

Don’t ask:

“What scanner should I run?”

Ask:

“What do I know about this application that I didn’t know 30 minutes ago?”

That mindset changes everything.

Recon Is an Iterative Process

You discover:

Subdomain.

That reveals:

Technology.

Technology reveals:

JavaScript.

JavaScript reveals:

API.

API reveals:

Authentication model.

Authentication model reveals:

Interesting workflow.

And suddenly:

One clue leads to another.

That’s good recon.

A Practical Recon Pipeline

A clean workflow can look like:

1. Read scope
      ↓
2. Organization OSINT
      ↓
3. Domain discovery
      ↓
4. Subdomain enumeration
      ↓
5. DNS resolution
      ↓
6. Live-host validation
      ↓
7. Technology fingerprinting
      ↓
8. JavaScript analysis
      ↓
9. API discovery
      ↓
10. Historical discovery
      ↓
11. Cloud/infrastructure mapping
      ↓
12. Manual verification
      ↓
13. Prioritization
      ↓
14. Vulnerability testing
      ↓
15. Evidence + report

Notice something?

Vulnerability testing comes late.

Passive Recon First

A strong beginner workflow starts with information that already exists publicly.

For example:

• Search engines
• Certificate transparency
• Public DNS
• Public repositories
• Public documentation
• Internet archives

Why?

Because passive discovery is usually:

Lower risk.

Lower noise.

Easier to automate.

Less likely to violate program restrictions.

Then Move to Low-Impact Active Recon

Once you understand the scope:

DNS resolution.

HTTP requests.

Basic service identification.

Controlled crawling.

Keep your activity:

Slow.

Predictable.

Within program limits.

Rate Limits Are Not Suggestions

If a bug bounty program says:

5 requests/second

don’t run:

500 requests/second.

Even if you can.

Security research should not become:

Denial of service.

Don’t Scan the Entire Internet

This should be obvious.

Don’t take a discovered IP and start:

Masscan

Aggressive Nmap scripts

Vulnerability scanners

unless you have clear authorization and the activity is allowed.

For bug bounty:

Scope beats curiosity.

What Tools Can Fit Into This Workflow?

A typical authorized recon toolkit might include:

Asset discovery

• Amass
• Subfinder
• Assetfinder

DNS

• dig
• nslookup
• dnsx

HTTP validation

• httpx

Crawling

• Katana
• Burp Suite crawler

Technology identification

• Wappalyzer
• WhatWeb

Historical discovery

• Wayback Machine
• Common Crawl

Interception/manual testing

• Burp Suite
• OWASP ZAP

The exact tool doesn’t matter nearly as much as:

Knowing why you’re running it.

Burp Suite Belongs Later Too

Burp Suite is incredibly useful.

But don’t open it and immediately start throwing payloads everywhere.

First understand:

Application structure.

Requests.

Authentication.

API endpoints.

Parameters.

User roles.

Then use Burp to inspect and manually test interesting functionality.

Build Your Own Recon Database

Don’t rely on terminal output scrolling past.

Store results.

For example:

target/
├── scope.txt
├── domains.txt
├── subdomains.txt
├── resolved.txt
├── live.txt
├── urls.txt
├── javascript.txt
├── endpoints.txt
├── technologies.txt
├── screenshots/
└── notes.md

This makes recon repeatable.

Add Timestamps

Record:

When was this asset discovered?

Why?

Because infrastructure changes.

Something that was:

404

last month may be:

Live

today.

Historical comparison can reveal:

New deployments.

New subdomains.

New technologies.

Track Changes

One of the most powerful recon techniques isn’t:

Finding everything once.

It’s:

Finding what’s new.

Run authorized discovery periodically.

Compare:

Yesterday
vs.
Today

New asset?

Investigate.

New API?

Investigate.

New technology?

Investigate.

Recon Can Become a Change-Detection System

Imagine:

Monday:
api.example.com
Tuesday:
api.example.com
dev-api.example.com
Wednesday:
api.example.com
dev-api.example.com
staging-api.example.com

You now know:

Something changed.

New infrastructure can be particularly interesting for research because it may not yet be familiar to the broader security community.

But Don’t Automatically Attack New Assets

A new hostname is:

A lead.

Not:

Permission.

Confirm it is within the bounty scope.

OSINT Is the Context Layer

OSINT can tell you:

What the company publicly reveals.

Recon tells you:

What infrastructure exists.

Testing tells you:

Whether something is actually vulnerable.

These are related but different disciplines.

Think of Them as Three Layers

OSINT
"What does the world know?"
        ↓
RECON
"What assets exist?"
        ↓
SECURITY TESTING
"Is anything actually vulnerable?"

The strongest researchers connect all three.

A Simple Example

Imagine a company announces:

“We’ve launched our developer platform.”

OSINT finds:

developers.example.com

Recon discovers:

api.developers.example.com

JavaScript reveals:

/v2/projects

Documentation reveals:

Project IDs.

Now you have a clear area to investigate.

The vulnerability, if one exists, would still need to be demonstrated safely and within scope.

Recon Can Reveal Business Logic Too

Don’t only look for:

Ports.

Domains.

IPs.

Look for:

• User roles
• Account types
• Subscription tiers
• Workflows
• APIs
• Administrative functions
• Object relationships

Because many serious vulnerabilities aren’t infrastructure bugs.

They’re:

Logic bugs.

Learn the Application Before Trying to Break It

If you don’t understand:

How users register.

How users authenticate.

How accounts interact.

How objects are created.

How permissions work.

you’ll struggle to identify:

Broken access control.

Recon for APIs

For each API, document:

Endpoint
HTTP method
Authentication
Parameters
Response
Object IDs
Role requirements

Then ask:

What happens if the user changes something they shouldn’t control?

That becomes a much more targeted security investigation.

Recon for Authentication

Map:

• Registration
• Login
• Password reset
• MFA
• Email verification
• Session management
• OAuth
• Account recovery

Don’t attack these blindly.

Understand the workflow first.

Recon for Authorization

Identify:

Normal user

Premium user

Admin

Support

Organization owner

Then understand what each role is supposed to access.

This creates a foundation for testing:

Broken access control.

The Best Recon Question

At every stage ask:

“What assumption is the application making?”

For example:

“Users can’t access another user’s object.”

Then test that assumption within the program’s rules and with safe test accounts/data.

That’s how recon turns into meaningful vulnerability research.

What Beginners Get Wrong

❌ Running every scanner

More tools don’t equal better research.

❌ Ignoring scope

This can get you banned.

❌ Treating every finding as a vulnerability

A banner isn’t a bug.

❌ Collecting thousands of URLs without understanding them

Noise.

❌ Forgetting APIs

Modern applications often depend heavily on APIs.

❌ Ignoring JavaScript

It can reveal application structure.

❌ Ignoring historical assets

The past can reveal useful context.

❌ Never documenting results

You end up repeating work.

❌ Testing aggressively

Bug bounty programs are not your private lab.

Build Your Own Recon Methodology

Don’t memorize:

50 commands.

Memorize the process.

SCOPE
  ↓
DISCOVER
  ↓
VERIFY
  ↓
UNDERSTAND
  ↓
MAP
  ↓
PRIORITIZE
  ↓
TEST
  ↓
DOCUMENT

Tools will change.

The methodology won’t.

Recon Is a Skill, Not a Command

Anyone can copy:

subfinder -d example.com

The difficult part is understanding:

What do I do with the results?

That’s where real skill develops.

Your First Bug Bounty Recon Checklist

Before testing:

• Read the scope
• Record exclusions
• Identify official domains
• Enumerate authorized subdomains
• Resolve discovered hosts
• Identify live services
• Fingerprint technologies
• Inspect JavaScript
• Identify APIs
• Review public documentation
• Check historical URLs
• Review authorized cloud references
• Map application functionality
• Create notes
• Prioritize targets
• Begin manual testing

The Real Goal of Recon

At the beginning:

“I have a domain.”

After good recon:

“I understand the organization’s authorized attack surface.”

You know:

• What exists.
• What’s live.
• What’s important.
• What technology is running.
• How applications communicate.
• Where APIs live.
• What has changed.
• Which areas deserve manual research.

That’s when vulnerability hunting becomes much more efficient.

Final Thoughts

Bug bounty hunting isn’t:

Run scanner → get CVE → submit report.

Real research often starts much earlier.

It starts with:

Questions.

What domains exist?

What applications exist?

Which ones are new?

What APIs exist?

What technologies are being used?

What changed?

How does the application work?

What assumptions does it make?

Where are the trust boundaries?

And eventually:

Where could that assumption fail?

The best recon isn’t the recon that produces the most output.

It’s the recon that produces the:

Most useful understanding.

Stay within scope.

Start passive.

Move carefully into active testing.

Document everything.

Verify before reporting.

And remember:

Recon doesn’t find vulnerabilities by itself.

Recon tells you where to look—and why.