Bug Bounty Methodology and Responsible Disclosure

Bug bounty programs pay you to find vulnerabilities in companies that have invited you to look. The invitation is the whole point. Everything here assumes you are working inside a program’s published rules.

Read the scope like a lawyer

The program policy is a legal document, and it is your authorization. Before you send a single request:

• In-scope assets. Exactly which domains, apps, and APIs. *.example.com and www.example.com mean very different things.
• Out-of-scope assets. Third-party services, acquisitions, and staging are often excluded explicitly.
• Forbidden techniques. Denial of service, social engineering, physical access, and automated scanning above a rate limit are commonly banned.
• Excluded bug classes. Many programs won’t pay for missing headers, self-XSS, or logout CSRF. Don’t spend a week on them.
• Safe harbor. Good programs promise not to pursue legal action if you follow the rules. Prefer those programs.

If anything is ambiguous, ask the program through the platform before you test.

Pick programs where you can win

New hunters flock to the biggest programs and compete with thousands of people for the same easy bugs. Better options:

• Programs launched recently, which haven’t been picked clean yet.
• Programs with large, complex scope: many apps, many features, many roles.
• Programs in industries you already understand. Domain knowledge finds business-logic bugs that scanners can’t.

Depth beats breadth

The hunters who earn the most usually know one application extremely well. Spend days using the product as a real customer:

1. Create accounts at every role and tier: free, paid, admin, invited user.
2. Map every feature and write down what each role should and shouldn’t be able to do.
3. Test those assumptions with Burp. Can a free user call a paid-tier API? Can a removed team member still read team data?

These authorization and business-logic bugs are under-tested because automated scanners can’t understand them, and they usually pay well.

Lesser-known places bugs hide

• Old API versions. If the app uses /api/v3/, check whether /api/v1/ still exists and still enforces the same checks.
• Mobile apps. They often call different or older endpoints than the website does.
• Exports and imports. CSV export, PDF generation, and file import features process data in unusual ways.
• Invite and sharing flows. Tokens in invite links, link-sharing permissions, and ownership transfer are frequent sources of access control bugs.
• Changelogs and docs. Public release notes tell you exactly which features are new, and new code has the most bugs.

Write a report that gets paid

A triager reads dozens of reports a day. Make yours impossible to misunderstand:

## Summary
A free-tier user can read any team's invoices by changing the team ID in
GET /api/v2/teams/{id}/invoices.

## Steps to reproduce
1. Log in as free user A (team 1001).
2. Send GET /api/v2/teams/1002/invoices with A's session.
3. Observe team 1002's invoices returned with HTTP 200.

## Impact
Any authenticated user can read billing names, addresses, and amounts
for every customer. I tested only against two accounts I created.

## Suggested fix
Verify the requesting user belongs to {id} before returning data.

• Lead with impact in one sentence.
• Make the reproduction steps copy-pasteable.
• Show you limited your access to accounts you own. Never pull more real customer data than you need to prove the issue.
• Don’t exaggerate severity. Accurate reports build reputation, and reputation earns private invitations.

When there’s no bounty program

If you stumble on a vulnerability somewhere without a program, look for /.well-known/security.txt, which lists the official security contact. Report what you saw, stop testing, and don’t access any more data. Coordinated disclosure norms give vendors a reasonable window, commonly 90 days, to fix the issue before details are published.