Bug-bounty research

Organize a narrow hypothesis, compare HTTP evidence and write a report another researcher can reproduce.

A bounty report needs a defensible impact statement and a repeatable path to it. A long list of possible vulnerabilities does little for triage. Start with one behavior that differs from the application’s intended rule.

Use the conversation to keep requests, observations and alternative explanations together. The model can help narrow the hypothesis and draft checks; the finding depends on the evidence you collect.

Start with this material

  • The program scope and the specific feature under review, without private program secrets.
  • A minimal request and response from synthetic accounts, with session tokens removed.
  • The expected behavior, observed behavior and a record of any state changes made during the test.

Work through the evidence

  1. State one hypothesis, such as a non-owner reading a report by changing its identifier. Identify the response field that would prove it.
  2. Compare the baseline with a single changed input. Check whether caches, account roles or object visibility explain the result.
  3. Ask for an impact statement limited to the tested action and data. Keep proposed extensions in a separate list of unverified questions.
  4. Draft exact reproduction steps with prerequisites and cleanup. Review every identifier and screenshot before submitting through the program’s own channel.

A prompt to adapt

Adapt to your evidence
Help turn these two HTTP exchanges into a reproducible access-control report. Account B does not own Account A’s synthetic report. List the prerequisites, the one changed parameter and the response evidence. Identify alternative explanations to rule out. Draft an impact statement that stays within what these exchanges prove.

Check the result

  • A fresh test identity can reproduce the behavior without relying on an unexplained browser state.
  • The report names the affected operation and actual exposed field, rather than claiming a wider compromise.
  • The submitted material excludes credentials and unrelated user data and includes steps to remove synthetic test objects.

Bring your own evidence into a conversation and work through the next question.

Open chat