Bug Bounty Hunting Process

Por

Bug Bounty Programs

As highlighted in the summary of this module, a bug bounty program is generally viewed as a crowdsourcing initiative where individuals are rewarded—both with recognition and financial incentives—for finding and responsibly reporting software vulnerabilities.

However, these programs go beyond simple rewards. A bug bounty program (often referred to as a Vulnerability Rewards Program – VRP) represents ongoing, proactive security testing. It complements in-house code reviews and penetration testing while strengthening an organization’s overall vulnerability management strategy.

HackerOne describes its platform, which hosts such programs, as “Continuous testing, constant protection”—a solution that integrates smoothly into an organization’s existing development lifecycle.

Types of Bug Bounty Programs

Bug bounty programs typically fall into two categories: private and public.

  • Private Programs
    Private bug bounty programs are not open to the general public. Only invited researchers can participate. Most initiatives start privately, allowing organizations to learn how to handle vulnerability reports before opening them to everyone. Invitations are usually based on a researcher’s past performance, reliability of findings, and history of rule compliance. For example, HackerOne uses specific criteria to send out invitations, and in some cases, programs may even request a background check.
  • Public Programs
    Public programs are accessible to the entire security research community without restrictions.
  • Parent/Child Programs
    Some organizations run programs where a parent company and its subsidiaries share a bounty pool and security team. If a subsidiary creates its own initiative, it links back to the parent program.

Important distinction: Bug Bounty Programs (BBPs) and Vulnerability Disclosure Programs (VDPs) are not the same.

  • A VDP only sets out how an organization wants to receive vulnerability information.
  • A BBP actively encourages discovery by offering rewards for valid bug reports.

For more details, see VDP vs. BBP.

Code of Conduct in Bug Bounty Programs

A researcher’s violation history is always taken into account. That’s why following the rules and code of conduct for each program or platform is critical. These documents don’t just outline behavioral expectations—they also help hunters become more efficient and successful in submitting reports.

To establish yourself as a trusted bug bounty researcher, you need to balance professionalism with technical expertise.

A good starting point is reviewing HackerOne’s Code of Conduct.

Structure of a Bug Bounty Program

To understand how these programs are organized, review some examples in HackerOne’s Bug Bounty Program List, such as the Alibaba BBP or the Amazon Vulnerability Research Program.

According to HackerOne, the policy section of a program communicates its rules and scope. Organizations usually define:

  • How they want to receive vulnerability information
  • Which assets are in scope (e.g., domains, IP ranges, mobile apps)
  • Which areas are out of scope

A standard bug bounty policy often includes:

  • Vendor Response SLAs – timelines for replies
  • Access – details on creating or obtaining test accounts
  • Eligibility Criteria – e.g., only the first valid report qualifies
  • Responsible Disclosure Policy – rules for safe and coordinated disclosure
  • Rules of Engagement – what’s allowed and what’s not
  • Scope / Out of Scope – assets eligible for testing vs. excluded ones
  • Reporting Format – structure of vulnerability reports
  • Rewards – compensation details
  • Safe Harbor – protection for researchers following the rules
  • Legal Terms and Conditions
  • Contact Information

These details, typically under the program’s Policy, should always be reviewed carefully to avoid misunderstandings. In bug bounty hunting, efficiency matters—and wasting time on avoidable mistakes can cost opportunities.

How to Find Bug Bounty Programs

One of the most useful resources for discovering new programs is the HackerOne Directory. This directory lists organizations with bug bounty initiatives and also provides contact details for responsibly reporting vulnerabilities you may find.

Which Bug Bounty Program part establishes expectations for behavior while participating in a bug bounty program?

[REDACTED]

Writing a Good Report

Clear, concise documentation gets your point across quickly and lets the security or triage team act on your findings. The most important part of any bug report is a reproducible, step-by-step explanation of how to exploit the vulnerability.

Remember: when you’re reporting to less mature organizations, translate technical findings into plain business language so non-technical stakeholders understand the real risk and impact.

Essential elements of a strong bug report

(Order may vary, but include each item where relevant.)

  • Vulnerability Title — Short, descriptive name including type, affected domain/parameter/endpoint, and impact.
  • CWE & CVSS score — Common Weakness Enumeration for classification and CVSS to express severity.
  • Vulnerability Description — Clear explanation of the root cause and how the flaw occurs.
  • Proof of Concept (PoC) — Repro steps that demonstrate the issue concisely and unambiguously.
  • Impact — What an attacker can achieve if the flaw is fully exploited; include business impact and worst-case damage.
  • Remediation — Fix recommendations (optional in many bounty programs, but very helpful).

Well-formatted, readable reports reduce the time required to reproduce issues and speed up triage.

Why include CWE & CVSS?

CWE (Common Weakness Enumeration) is a community-maintained taxonomy of software and hardware weakness types. It gives teams a common vocabulary and helps guide mitigation and prevention. If the issue is part of a chain, pick the CWE tied to the initial weakness.

CVSS (Common Vulnerability Scoring System) is a standardized method to quantify the severity of a vulnerability. Use CVSS v3.1 when you want to communicate severity in an industry-recognized way.

Using the CVSS v3.1 calculator (Base Score focus)

We’ll concentrate on the Base Score group of metrics. These define the inherent technical severity of the vulnerability.

Attack Vector (AV) — how the attacker reaches the vulnerable component.

  • Network (N): Remotely exploitable over a network.
  • Adjacent (A): Requires network proximity (same subnet/VPN).
  • Local (L): Requires local access (console/SSH/user session).
  • Physical (P): Requires physical contact or manipulation.

Attack Complexity (AC) — additional conditions required to exploit.

  • Low (L): No special conditions — easy to exploit repeatedly.
  • High (H): Exploitation needs special setup or information.

Privileges Required (PR) — what access the attacker needs beforehand.

  • None (N): No privileges required.
  • Low (L): Standard user privileges.
  • High (H): Administrator/root privileges.

User Interaction (UI) — whether a victim must take action.

  • None (N): Exploit runs without user help.
  • Required (R): Exploit needs user involvement.

Scope (S) — whether exploitation affects components beyond the vulnerable one.

  • Unchanged (U): Impact stays within the same security scope.
  • Changed (C): Other components or security authorities can be impacted.

Confidentiality (C) — amount of information disclosure on successful exploit.

  • None (N), Low (L), High (H) — from no disclosure up to total data exposure.

Integrity (I) — how much data trustworthiness is affected.

  • None (N), Low (L), High (H) — from no modification to full control over data.

Availability (A) — how much service accessibility is affected.

  • None (N), Low (L), High (H) — from no impact to total denial of service.

Example CVSS assessments

Cisco ASA IKE Buffer Overflow (CVE-2016-1287)

  • CVSS 3.1 Score: 9.8 (Critical)
  • AV: Network — device was internet-exposed.
  • AC: Low — public exploit available.
  • PR: None — attacker need not authenticate.
  • UI: None — no user interaction.
  • S: Unchanged — impact limited to the device itself.
  • C/I/A: High — full compromise (reverse shell), data/modification and availability loss possible.

Stored XSS in an admin panel (Malicious Admin → Admin)

  • CVSS 3.1 Score: 5.5 (Medium)
  • AV: Network — reachable over the internet.
  • AC: Low — attacker only needs to store the payload.
  • PR: High — requires admin privileges to insert payload.
  • UI: None — other admins are affected simply by visiting the page.
  • S: Changed — server vulnerability affects client browsers.
  • Confidentiality: Low — DOM access possible.
  • Integrity: Low — limited ability to alter data.
  • Availability: None — cannot cause a DoS via this XSS.

Good report examples

HackerOne lists high-quality reports that are good references, such as:

  • SSRF in Exchange leading to root access across instances
  • Remote code execution in Slack desktop apps (plus bonus material)
  • Exposure of full names via NR API Explorer
  • Low-privilege staff editing customer email
  • XSS in login flows and public pages

For the exact submission workflow, consult HackerOne’s Submitting Reports documentation to ensure your report follows the platform’s required steps.

Which base metric value of the base score considers that attackers can only exploit a vulnerability if they reside in the same physical or logical network as the target host/application?

[REDACTED]

Interacting with Organizations/BBP Hosts

Submitting a bug report is only the first step. How you interact with the security/triage team afterward is just as important as the technical quality of your findings. Professional communication increases trust, speeds up resolution, and strengthens your reputation as a researcher.

Initial Contact: Do Not Rush

  • Wait before following up. After submitting a report, allow the triage team time to process it. They need to validate your findings, reproduce the issue, and sometimes involve other stakeholders.
  • Respect platform SLAs. Bug bounty platforms often provide vendor response SLAs (Service Level Agreements) or efficiency metrics. Use these as a reference for expected response times.
  • Avoid spamming. Do not send repeated follow-ups in a short period of time—this frustrates teams and may harm your credibility.

If No Response

  • Check platform mediation. If you submitted through a bug bounty platform (e.g., HackerOne, Bugcrowd, Intigriti), and the company hasn’t responded within a reasonable time, contact Mediation or the equivalent support feature.
  • Stay professional. Never attempt to escalate by reaching out over social media, LinkedIn, or other unofficial channels. Always stick to the official communication paths.

Ongoing Communication

  • Note the responder. Once the triage team replies, identify the assigned team member (often shown by their username). Tag them in follow-ups to maintain consistent communication.
  • Stay calm and professional. Even if the process is slow or the team disagrees with your assessment, remain courteous and clear. Treat the interaction as if it were part of your job.

Handling Disagreements

Disputes often arise over severity scoring or bounty amounts. Handle these methodically:

  1. Justify your CVSS scoring. Walk the triage team through each Base Metric (Attack Vector, Complexity, Privileges, Scope, CIA impact). This shows your reasoning and encourages alignment.
  2. Cross-check scope & policy. Ensure the vulnerability is within program scope and that your reward expectation is consistent with the program’s stated rules.
  3. Escalate if needed. If disagreements persist after professional discussion, escalate to Mediation via the bug bounty platform. This ensures fairness while keeping communication structured.

Key Principles

  • Patience first, professionalism always.
  • Respect official channels. No off-platform or informal communication.
  • Be evidence-driven. Back up claims with CVSS metrics, CWE references, and clear PoCs.
  • Know the program policy. Avoid arguing for rewards outside stated rules.

Example 1 — Stored Cross-Site Scripting (XSS) Report (Rewritten)

Title: Stored Cross-Site Scripting (XSS) in X Admin Panel

CWE: CWE-79 — Improper Neutralization of Input During Web Page Generation (Cross-site Scripting)

CVSS v3.1: 5.5 (Medium)

Summary / Description

During our assessment we discovered that the X for administrators web application fails to properly sanitize an uploaded file’s filename. The filename is both stored in the application database and reflected back into administrators’ browsers when viewing uploaded files. Because the filename can contain executable JavaScript and is not escaped/sanitized, the application is vulnerable to both stored and reflected XSS. An attacker who can upload files (for example, an administrator) may craft a filename that injects script which will execute when other administrators view the file listing or details.

Impact

XSS allows an attacker to inject client-side scripts that execute in the context of other users’ browsers. Successful exploitation can lead to theft of session cookies, account takeover, arbitrary JavaScript execution in the victim’s browser, UI manipulation, or redirecting users to malicious sites. Because uploaded files and their filenames are visible to all administrators, any admin user can be targeted. This creates a meaningful risk when privileged users are exposed to injected scripts.

Proof of Concept (PoC) — Reproduction Steps

  1. Create an upload with a malicious filename. From a Linux machine (or any file system that allows these characters), create or rename a file using a filename that contains an XSS payload, for example:
javascript
"><svg onload=alert(document.cookie)>.docx
  1. Upload the file using the application’s file upload functionality:
    Admin Info → Secure Data Transfer → Load of Data
  2. Observe stored payload execution. When another administrator clicks View (or otherwise loads the uploaded file listing/details), the browser will render the malicious filename and execute the embedded JavaScript, producing an alert with the victim’s session cookie (or other script behavior).

Observed result: The injected script in the filename executes in the admin’s browser context when the file is viewed.

CVSS v3.1 — Base Metrics (Breakdown)

  • Attack Vector (AV): Network — The vulnerable functionality is reachable over the network.
  • Attack Complexity (AC): Low — No special conditions are required beyond uploading a crafted filename.
  • Privileges Required (PR): High — The upload/view functionality is limited to admin users.
  • User Interaction (UI): None — Other admins are affected simply by viewing the page.
  • Scope (S): Changed — The server-side vulnerability results in code execution in the client (browser) context.
  • Confidentiality (C): Low — DOM access may allow exposure of some data (e.g., cookies or visible fields).
  • Integrity (I): Low — XSS can perform limited modifications to the page or data exposed in the browser.
  • Availability (A): None — This XSS does not directly enable denial of service.

Notes & Mitigation Suggestions (brief)

  • Properly escape/encode filenames before rendering them in HTML contexts (e.g., HTML entity encode <, >, ", &), or sanitize filenames on upload to remove potentially executable characters.
  • Consider rendering filenames as plain text (not HTML) or using a server-side whitelist of allowed characters.
  • Apply Content Security Policy (CSP) headers to mitigate impact of injected scripts.
  • Validate and normalize uploaded filenames server-side and store a sanitized display name while preserving original name if needed in logs.

Example 2 — Cross-Site Request Forgery (CSRF) Report (Rewritten)

Title: Cross-Site Request Forgery (CSRF) in Consumer Registration

CWE: CWE-352 — Cross-Site Request Forgery

CVSS v3.1: 5.4 (Medium)

Summary / Description

During our assessment we found that the consumer registration endpoint accepts state-changing POST requests without anti-CSRF protections. An attacker can craft a web page that issues a POST to /consumer-registration with parameters for application type, name, developer email and description. If a victim who is authenticated and has an active session visits that page, the browser will submit the request using the victim’s credentials/session, causing the server to perform the action on the victim’s behalf (e.g., register a fintech application and issue API keys).

CSRF typically targets operations that change server state (account settings, purchases, registrations). Its impact depends on the privileges of the victim’s account — the attacker inherits those privileges when the forged request executes.

Impact

If exploited, an attacker could perform any action the authenticated user is allowed to do. In this case, an attacker can cause an authenticated user to create a fintech application and obtain consumer keys/API credentials under the victim’s account. Combined with other findings (for example an XSS allowing silent CSRF injection or token exfiltration), the risk increases significantly. The overall impact is constrained only by the victim’s privileges.

Proof of Concept (PoC) — Reproduction Steps

Prerequisites: A victim with an active authenticated session.

  1. Intercept or observe a valid registration request using a proxy while registering a fintech application:
POST /consumer-registration
Content-Type: application/x-www-form-urlencoded

type=Web&name=MyApp&developer_email=dev@example.com&description=desc
  1. Construct a malicious HTML page that issues the same POST when loaded (example using an auto-submitting form):
<html>
  <body onload="document.forms[0].submit()">
    <form action="https://target.example.com/consumer-registration" method="POST">
      <input type="hidden" name="type" value="Web">
      <input type="hidden" name="name" value="Unwanted_FinTech_App">
      <input type="hidden" name="developer_email" value="attacker@example.com">
      <input type="hidden" name="description" value="Created via CSRF">
    </form>
  </body>
</html>
  1. Send the malicious page/link to a victim who is logged in to the target application. When the victim visits the page, the browser will POST to /consumer-registration using the victim’s session cookie—resulting in the inadvertent creation of the attacker-controlled fintech application and issuance of consumer keys.

Observed result: New application created under the victim’s account (example output: application type = Web, name = Unwanted_FinTech_App, consumer keys visible).

CVSS v3.1 — Base Metrics (Breakdown)

  • Attack Vector (AV): Network — Exploitable over the web.
  • Attack Complexity (AC): Low — Requires just a single user visit while authenticated.
  • Privileges Required (PR): None — Attacker does not need special privileges to craft the page.
  • User Interaction (UI): Required — The victim must visit the malicious page or click a crafted link.
  • Scope (S): Unchanged — Impact is limited to the same security authority (the webserver/application).
  • Confidentiality (C): Low — Attacker may obtain limited information (e.g., API keys issued).
  • Integrity (I): Low — Attacker can create or modify data (create an application) but does not fully compromise system integrity.
  • Availability (A): None — CSRF in this form does not cause denial of service.

Mitigation & Recommendations

  1. Implement Anti-CSRF Tokens: Require a server-validated CSRF token for all state-changing requests (POST/PUT/DELETE). Use tokens tied to the user session and validate server-side.
  2. SameSite Cookies: Set session cookies with SameSite=Lax or SameSite=Strict where compatible to limit cookie sending on cross-site requests.
  3. Validate Origin/Referer: For sensitive POST endpoints, verify the Origin or Referer header to ensure the request originates from your site. Reject requests with missing or mismatched headers.
  4. Require Re-auth for Sensitive Actions: For high-impact operations (issuing API keys, changing account credentials), require recent re-authentication or an additional confirmation step.
  5. Use CORS Correctly: Ensure CORS policies do not unintentionally allow cross-origin POSTs from arbitrary domains.
  6. Avoid Blind GET Side-Effects: Ensure state changes cannot be triggered by GET requests.
  7. Defense in Depth: Combine CSRF tokens with SameSite and origin checks for stronger protection.