Bug bounty for developers is the most natural pivot in security, because you already know where apps break — you have shipped the exact endpoints that leak data when an authorization check is missing. The catch that trips up beginners is not skill, it is scope: bug bounty is paid, authorized testing against targets that have explicitly invited it, and nothing else. Test only assets listed in a program's scope, follow its rules of engagement to the letter, and never touch a system you were not invited to. Unauthorized testing — even with good intentions — is a crime in most jurisdictions, not a hobby. Get that one thing right and the rest is applying instincts you already have: the IDOR you almost shipped last quarter, the cookie that was missing HttpOnly, the upload form that trusted the client. This post is how I would start over, ethically, from a developer's seat.
What is a bug bounty program, exactly?
A bug bounty program is a public or private invitation from a company to find and responsibly disclose security vulnerabilities in defined assets, in exchange for recognition or money. Programs run either on platforms like HackerOne and Bugcrowd, which standardize scope, reporting, and payouts, or as self-hosted vendor programs (Google, GitHub, GitLab, and many others publish their own). Every program ships a scope page and a rules-of-engagement document. Read both before you send a single request. They tell you which domains and apps are in scope, which are explicitly out, what testing is forbidden (automated scanners, DoS, social engineering, testing other users' accounts), and how to report.
The mental model that keeps you safe: the scope page is a contract. If a subdomain is not listed, it is out — treat it as someone else's property, because it is. If the rules say no automated scanning, a noisy scanner run can get you banned and, worse, can break production for real users. The programs that pay best are the ones that trust researchers, and that trust is built on staying inside the lines.
- In scope: the exact domains, apps, and APIs listed — for example *.app.example.com but NOT *.example.com. Read the wildcard carefully.
- Out of scope: anything not listed, third-party services the target merely uses, and any finding class the program explicitly excludes (often self-XSS, missing headers alone, or rate-limiting reports without impact).
- Forbidden actions: DoS/load testing, social engineering of staff, physical attacks, and accessing or modifying other users' data beyond the minimum needed to prove a bug.
- Safe-harbor language: good programs include a statement that they will not pursue legal action for good-faith research within scope. If a program has no safe harbor, weigh that risk before testing.
Why do developers have an edge?
Every bug class that pays well is something you have already built and, somewhere, gotten wrong. You do not need to learn what these vulnerabilities are from scratch — you need to learn to look for them from the outside. That reframe is the whole job.
IDOR and broken object-level authorization
IDOR (insecure direct object reference) is the highest-value-for-effort class for developers, because you have written the buggy version. It is any endpoint that fetches a record by an ID from the request without checking that the authenticated user is allowed to see that record. If you have ever written a Laravel controller that did Invoice::findOrFail($request->id) and returned it without scoping the lookup to the current user — say Invoice::where('user_id', auth()->id())->findOrFail($request->id), or a policy check — you already understand it. From the outside, you find it by capturing a request, noting an object identifier, and changing it to one that belongs to a different account you control.
# Log in as YOUR account A, capture a request that returns YOUR data.
# Note the object id in the path or body (here: 1001).
curl -s 'https://app.example.com/api/invoices/1001' \
-H 'Authorization: Bearer <TOKEN_FOR_ACCOUNT_A>' | jq .
# Now request a neighbouring id while STILL authenticated as A.
# If account A can read invoice 1002 (which belongs to account B,
# a second test account YOU also control), that is an IDOR.
curl -s 'https://app.example.com/api/invoices/1002' \
-H 'Authorization: Bearer <TOKEN_FOR_ACCOUNT_A>' -i
# Rule: only ever pivot between accounts you own. Never read a
# real stranger's data to "confirm" the bug — the 403-vs-200
# distinction is enough to prove it.Beyond IDOR, the rest of the developer-friendly map: stored and reflected XSS (you know which fields skip output encoding), authentication and session flaws (predictable reset tokens, sessions that survive logout, missing re-auth on email change), business-logic bugs (negative quantities, applying a coupon twice via a race, skipping a payment step in a multi-stage checkout), exposed secrets in JS bundles or public repos, and plain misconfiguration (debug mode on in production, an open admin panel, a verbose stack trace). Business logic is where developers genuinely out-hunt generalists, because finding it requires understanding what the application is supposed to do — and you have built that exact flow.
How do I actually start without breaking the law?
The order matters. Learn the proxy and practice on intentionally-vulnerable labs first, then read disclosed reports, then pick one beginner-friendly program and go deep rather than spraying across twenty.
Set up a proxy and practice legally
Your core tool is an intercepting proxy — Burp Suite (the free Community edition is enough to start) or the open-source OWASP ZAP. It sits between your browser and the target so you can read and modify every request. Before you point it at any real program, practice on targets built to be hacked: PortSwigger's Web Security Academy, OWASP Juice Shop, and DVWA. These are legal, free, and teach the exact request-manipulation muscle memory you need. The OWASP Web Security Testing Guide at owasp.org is the canonical methodology reference for what to test and how.
# A deliberately vulnerable app you are explicitly allowed to attack.
docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop
# Open http://localhost:3000 with your browser proxied through
# Burp or ZAP. Practise intercepting a login, tampering with a
# product-review request, and walking IDs on the basket endpoint.
# Everything you learn here transfers directly to real, in-scope
# targets — the difference is authorization, not technique.Then read disclosed reports. HackerOne's Hacktivity feed and public report disclosures are a free curriculum: real bugs, real repro steps, real payouts. Pick a class you understand — say IDOR — and read fifty disclosed IDOR reports. You will start seeing the patterns of where they live. When you move to a live program, choose one with a wide scope and a reputation for fast, fair triage, and spend a week mapping its application before you report anything.
The line between a researcher and a criminal is one word on the scope page. Authorization is not a formality you skim — it is the entire thing that makes this legal.
What makes a report get paid?
A finding is worth nothing until you can make a triager reproduce it in under two minutes. The reports that get paid fast and rated fairly share a structure: a one-line summary, exact reproduction steps with the requests included, a clear statement of real-world impact, and a suggested fix. The fix suggestion is where your developer background pays off twice — it speeds triage and it earns respect, because you are speaking the engineering team's language. I wrote about the receiving end of this in how to read and prioritize a security vulnerability report; writing reports that a busy team can act on is the same skill in reverse.
- Title: the bug class and location in one line — 'IDOR in /api/invoices/{id} allows reading any user's invoice'.
- Steps to reproduce: numbered, with the literal requests. Assume the triager has two of their own test accounts and nothing else.
- Impact: what an attacker actually gains — 'any authenticated user can read every other user's billing data and PII'. Tie it to the business, not the CVSS score alone.
- Proof: the minimum needed. Show a 200 where a 403 belonged, using only accounts you control. Redact other users' data if you encountered any.
- Suggested fix: the one-line server-side change — scope the query to the authenticated user, enforce object-level authorization in middleware or a policy.
On the fix angle: most of what you report maps to defensive patterns you should already be applying in your own code. If you build with Laravel, my security checklist for Laravel applications covers the authorization, session, and configuration controls that, when missing, become the exact bugs you will be reporting on other people's apps. Hunting and hardening are the same knowledge pointed in opposite directions, which is precisely why developers make good hunters.
Where this goes from here
Start narrow and honest. Get Burp running, clear a dozen Web Security Academy labs, read disclosed IDOR and access-control reports until the patterns are obvious, then pick one in-scope program and learn its application better than the people who built it. Keep every action inside the rules of engagement, prove bugs with accounts you own, and write reports a tired engineer can act on at 5pm on a Friday. The technical instinct you spent years building as a developer is the asset here — bug bounty just pays you to point it at things you are explicitly allowed to break. Stay in scope, document well, and the findings will come.
