Skip to content
Hugin capabilities

A bug bounty methodology that finds bugs

Most time lost on a target is lost before the first useful request — to poor scope reading and shallow mapping. This is the discipline that moves findings: scope, map, hypothesise, prove, then report.

The method

  1. 1

    Read the scope and rules first

    Know what is in scope, what is out, and what testing is allowed. A finding outside scope is not a finding, and a careless test can end your access. Write the scope down before you touch the target.

  2. 2

    Map the real attack surface

    Crawl the app, then drive it through every flow and capture the API calls behind the UI. The interesting endpoints are the ones the front-end hides — replays, exports, webhooks, admin paths.

  3. 3

    Pick high-yield classes

    For most web targets that is broken access control, authentication and session handling, SSRF, request smuggling, and logic abuse. Depth on three likely chains beats a shallow pass over thirty classes.

  4. 4

    Hypothesise, then probe

    For each surface, ask what could go wrong given the stack, then send the one request that confirms or kills the hypothesis. Kill dead ends fast; move to the next chain.

  5. 5

    Prove impact before writing up

    A finding needs an entry point, reproducible steps, proof (request/response, screenshot, or out-of-band callback), and the impact in one sentence. "Might be" is not a finding.

  6. 6

    Re-check adversarially

    Before submitting, attack your own finding: is it intended behaviour, is the impact real, would a triager reproduce it? Killing a weak finding saves a wasted cycle.

Do it in Hugin

Hugin is built around this loop: capture everything into one history, work the intercept-replay-intrude cycle for manual testing, and run the scanner, smuggling, race and OOB engines from the same binary — so the whole methodology lives in one tool instead of a cobbled pipeline.

Intercepting proxy capability

Frequently asked

What is the most important step in bug bounty?

Target and scope selection. A real product surface with two accounts where access control and logic bugs live beats anonymous probing of hardened infrastructure, every time.

How many bug classes should I test per target?

Go wide once to map the surface, then deep on the three most likely chains for that stack. Reportable bugs come from depth, not from ticking every class off a list.

Put the method into a tool

Hugin is free to download, no account.

Download Hugin

More guides