Getting Started

This guide is the shortest safe path through Bug Hunt Method Kit.

Who This Guide Is For

Use this if you are learning bug bounty workflow, organizing authorized security notes, reviewing a possible finding, or teaching safe evidence habits with fake examples.

Before You Test Anything

This repo does not give permission to test any real system. Scope means the exact places you are allowed to test. If scope is unclear, stop.

Do not use random guessing, brute force, OTP probing, credential attacks, payment manipulation, or repeated notification sends. If unexpected third-party data appears, stop and follow the program’s disclosure rules.

The Safe Workflow

The basic loop is:

permission -> boundary -> one hypothesis -> controlled test -> minimal evidence -> review -> decision

Step 1: Confirm Permission

Write down where permission comes from, what assets are in scope, what actions are allowed, and what actions are forbidden. Start with Session Brief.

Step 2: Define the Boundary

A boundary is the rule that separates what one user, account, role, tenant, or object is allowed to do from what it is not allowed to do.

Toy example:

USER_A owns OBJECT_1.
USER_B owns OBJECT_2.
USER_B should not read OBJECT_1.

Step 3: Write One Hypothesis

A hypothesis is one testable idea, not a pile of guesses.

Good:

USER_B may be able to read OBJECT_1 when only the object reference changes.

Weak:

Maybe authorization is broken everywhere.

Step 4: Use Tester-Controlled Accounts and Objects

Use only accounts and objects you control and are allowed to test. Never guess random object IDs. Never touch third-party data.

Step 5: Collect Minimal Evidence

Evidence means facts that prove what happened, not private data dumps. Record marker booleans, status, response length, cache headers when useful, and redacted summaries. Keep private evidence outside this public repo.

Step 6: Challenge the Finding Before Reporting

Ask:

Is the asset in scope?
Did the test prove a server-side boundary crossing?
Did it affect another tester-controlled account, object, role, or tenant?
Is the impact real, or only a confusing UI state?
Would a triager reject this as self-impact, intended behavior, or missing proof?

Use Pre-Submission Red Team Review.

Step 7: Decide What to Do Next

Impact means what unauthorized access, action, exposure, or privilege was actually proven.

Choose one:

reportable when scope, proof, boundary crossing, and impact are clear.
needs more proof when the idea is plausible but evidence is incomplete.
hardening note when useful but not a vulnerability.
discard when the behavior is intended, weak, unsafe, or not reproducible.
stop when safety boundaries are reached.

Common Beginner Mistakes

Testing before scope is clear.
Changing several values at once.
Treating ID mutation alone as proof.
Saving raw requests, cookies, tokens, or private response bodies.
Reporting stale UI when the server correctly denies fresh access.
Overstating severity before impact is proven.