Bug Bounty and Responsible Disclosure

Finding vulnerabilities in other people's software comes with responsibility. Responsible disclosure means reporting vulnerabilities to the organisation that can fix them, giving them time to act before public disclosure. Bug bounty programmes formalise this process with defined scope, rules, and often payment. This lesson covers how to find bugs ethically, write reports that get taken seriously, and work effectively with security teams.

Responsible disclosure basics

The disclosure spectrum

Always start with private or coordinated disclosure. Full disclosure should be a last resort after genuine, documented attempts to reach the vendor.

Finding the right contact

If the organisation has a security.txt file (RFC 9116), use the contact listed there. It specifies preferred language, encryption key, and reporting procedures.

What responsible disclosure looks like

1. Discover the vulnerability (within legal scope — your own software, or an authorised programme)
2. Document the issue with reproduction steps
3. Report through the organisation's preferred channel
4. Wait for acknowledgement and a fix timeline
5. Follow up if you have not heard back in 7 days
6. Agree on disclosure timeline (90 days is the standard, per Google Project Zero)
7. Do not exploit the vulnerability beyond what is needed to demonstrate it
8. Do not access, modify, or exfiltrate real user data
9. Do not disclose publicly before the agreed timeline

Bug bounty programmes

How they work

1. Organisation defines scope (which assets, in/out of scope, rules of engagement)
2. Researcher finds a vulnerability within scope
3. Researcher submits a report through the platform
4. Triage team validates and assesses severity
5. Organisation confirms and fixes
6. Researcher receives reward (if applicable)

Major platforms

Understanding scope

Always read the programme scope before testing. Common scope definitions:

In scope:
  - *.example.com
  - api.example.com
  - Mobile apps (iOS, Android)

Out of scope:
  - Third-party services (e.g., Zendesk, Intercom widgets)
  - Physical attacks
  - Social engineering of employees
  - Denial of service attacks
  - Automated scanning (unless permitted)

Testing out-of-scope assets can result in programme ban, legal action, or both.

What bounties pay

Bounty amounts vary widely by severity and programme:

Not all programmes pay. Many are Vulnerability Disclosure Programs (VDPs) that offer recognition but no payment.

Writing effective reports

A clear report gets fixed faster and rewarded more. A vague report wastes everyone's time.

Report structure

## Title
Descriptive title that identifies the vulnerability type and affected component.
Example: "IDOR in /api/orders allows any authenticated user to access other users' orders"

## Summary
One paragraph explaining the vulnerability, its impact, and the affected endpoint.

## Severity
Your assessment: Critical / High / Medium / Low
CVSS score if you can calculate it.

## Steps to Reproduce
1. Create two accounts: [email protected] and [email protected]
2. Log in as victim and create an order → note the order ID (e.g., 5001)
3. Log in as attacker
4. Send: GET /api/orders/5001 with attacker's auth token
5. Observe: attacker receives victim's full order details

## Proof of Concept
Include actual HTTP requests and responses (redact any real user data):

Request:
GET /api/orders/5001 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJ...attacker_token

Response:
HTTP/1.1 200 OK
{
  "orderId": 5001,
  "userId": 102,  ← this is victim's user ID, not attacker's
  "items": [...],
  "shippingAddress": "..."
}

## Impact
- Any authenticated user can access any order in the system
- Exposes PII: name, address, email, purchase history
- Estimated affected records: all orders in the database

## Suggested Fix
Add an ownership check:
SELECT * FROM orders WHERE id = $1 AND user_id = $2

## Environment
- Tested on: api.example.com
- Date: 2025-03-15
- Tools: curl, Burp Suite Community

Common report mistakes

After submitting

1. Wait patiently. Most programmes acknowledge within 1-5 business days.
2. Respond to questions. The triage team may ask for clarification.
3. Do not retest aggressively. Once reported, do not continue exploiting the vulnerability.
4. Do not disclose publicly. Wait for the agreed disclosure timeline.
5. Follow up politely if you have not heard back in 2 weeks.

Setting up a disclosure programme

If you are on the receiving end — running an application that others might find bugs in:

Minimum viable disclosure programme

1. Create /.well-known/security.txt:

Contact: mailto:[email protected]
Preferred-Languages: en
Expires: 2027-01-01T00:00:00.000Z
Policy: https://yourcompany.com/responsible-disclosure

2. Write a disclosure policy page with:

   • How to report (email, platform)
   • What is in scope
   • Safe harbour statement (you will not pursue legal action against good-faith researchers)
   • Expected response time
   • Whether you offer rewards

3. Set up a secure reporting channel:

   • Dedicated email address
   • PGP key for encrypted reports
   • Or use a platform like HackerOne or Bugcrowd

Handling incoming reports

Safe harbour

Include a safe harbour statement in your policy:

We will not pursue legal action against individuals who discover and report security vulnerabilities in good faith, within the scope of this policy, and in compliance with our guidelines.

Without safe harbour, researchers may not report findings for fear of legal action.

Legal considerations

• Computer Fraud and Abuse Act (CFAA) in the US and equivalent laws in other jurisdictions criminalise unauthorised access to computer systems
• Bug bounty programme scope defines what is "authorised"
• Testing outside scope, accessing real user data, or causing damage can result in criminal prosecution
• Always screenshot the scope and rules before testing — programmes can change their terms

Summary

Responsible disclosure protects users while giving organisations time to fix vulnerabilities. Always report through the proper channel — security.txt, bug bounty platform, or direct security contact. Write clear reports with reproduction steps, proof of concept, impact assessment, and a suggested fix. Respect programme scope, do not access real user data, and wait for the agreed disclosure timeline. If you run an application, create a security.txt, write a disclosure policy, and include a safe harbour statement.