Ravindra BagaleCourses & study guides मराठी Track your progress

35. Careers, Certifications and Bug Bounty

35.5 Bug Bounty

By Last updated:

Bug bounty programmes let companies invite outside researchers to find security bugs in their systems and reward valid reports, sometimes with money, swag or a hall-of-fame mention.

Platform / route Notes
HackerOne Large global platform with public and private programmes
Bugcrowd Another major platform
Intigriti, YesWeHack European platforms with many programmes
Company-run programmes Some companies run their own pages (look for "security", "responsible disclosure" or /.​well-​known/​security.​txt)

Golden rules:

  1. Read the programme policy fully. Only test assets listed in scope, only with allowed methods. Out-of-scope testing is unauthorised access (IT Act s. 43/66, Chapter 18).
  2. No damage: no denial of service, no mass automated scanning unless allowed, no accessing or downloading other users' data beyond what proves the issue.
  3. Use your own test accounts to show IDOR or access control issues (Chapter 29).
  4. Write a clear report: title, affected URL, severity, steps to reproduce, proof (screenshots, request/response), impact, and suggested fix.
  5. Keep it confidential until the company allows disclosure.

Sample report skeleton:

Title: IDOR allows viewing other users' invoices at /api/invoice?id=
Severity: High (CVSS reasoning included)
Steps: 1) Log in as test user A ... 2) Change id from 1041 to 1042 ... 3) Invoice of test user B is returned
Impact: Any logged-in user can read other customers' invoices (names, addresses, amounts)
Fix: Check invoice ownership on the server for every request

Ravindra Bagale's Tip

In bug bounty you get a lot of "duplicate" and "informative" results – don't be discouraged. At the start, focus not on easy targets but on new scope that few people have tested, do good recon, and write a very clear report. And don't send a single request without reading the policy.

Practice task

Open two public programmes on HackerOne or Bugcrowd and read their policies. For each, list: in-scope assets, out-of-scope assets, forbidden testing methods, and reward rules. Then write a practice report in the skeleton above for an IDOR you find in OWASP Juice Shop (local lab).

Extended teaching notes

Why this lesson matters

Hiring managers in India look for labs, clear ethics, and the ability to explain a fix. Certifications help; unauthorised testing destroys careers.

  1. Build a home lab and keep notes.
  2. Publish write-ups only for systems you own or public labs.
  3. Learn Linux, networking, one cloud, OWASP.
  4. Practice platforms: TryHackMe, HTB, PortSwigger Academy — under their rules.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

  1. Write the lesson title, date and the exact lab target you are allowed to use.
  2. List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
  3. Run one safe check from the lesson on a lab system only. Paste the command and output.
  4. Write a two-sentence fix you would give a teammate.
  5. Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

  • Control: a safeguard (patch, config, process, detection).
  • Finding: a weakness backed by evidence.
  • Remediation: the fix plus how you verified it.
  • Scope: systems you have written permission to touch.
  • Least privilege: only the access the task needs.
  • Defence in depth: several layers so one failure does not end the story.

Common mistakes

  • Skipping written permission "just for a quick scan".
  • Practising on hostel, office or public targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
  • Publishing screenshots that contain secrets, cookies or internal hostnames.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Fix > spectacle.