Getting started as a researcher

New researchers get stuck in two places: testing an asset nobody asked them to test, and writing a report a triager cannot reproduce.

Pick a program

Start at the program directory. Each listing shows scope size, whether the program pays cash or points only, median time to first response, and median time to bounty. Filter on three things:

• An asset type you already know. If you have never read Android bytecode, a mobile-only program is a slow way to learn.
• Response time. A program with a 10 day median first response will feel very different from one at 2 days.
• Scope breadth. Wide scope means more surface and more duplicates. Narrow scope means fewer collisions and harder bugs.

Read the policy and scope first

Read the full policy before you send a single request. The parts that decide whether your work counts:

• In-scope assets. Exact hostnames, whether wildcards include third-level domains, mobile bundle IDs, API versions.
• Out-of-scope assets and excluded findings. Most programs exclude self-XSS, missing headers without a demonstrated attack, and rate limiting on unauthenticated endpoints.
• Testing rules. Request-rate caps, mandatory test accounts, and the identifying header the program wants on your traffic, usually X-Sentinel-Researcher: <your-handle>.
• Reward table and severity rules. See severity and rewards for how bands are set.

Sentinel's safe harbor baseline applies to every program, but an individual policy may be stricter. The stricter text wins.

Set up an isolated test account

Register test accounts with a tagged address such as yourhandle+acme@researcher.example. Never test with your personal account, and never with an account that holds real data belonging to someone else.

Create two accounts, A and B, both yours. Access-control bugs are proven by having A reach B's object, and that proof is clean only when you own both sides. Set the identifying header in your proxy so the program can separate your traffic from a real incident.

Recon within scope only

Enumerate subdomains, endpoints, and parameters, then filter the results against the scope list before you probe anything. If an asset is not listed, treat it as out of scope even when it clearly belongs to the same company. Ownership is not permission.

Keep automated scanning slow and confined to in-scope hosts. A scanner that hammers a login endpoint looks exactly like an attack, and it is the fastest way to lose your account.

Reproduce twice before you report

Reproduce the bug a second time in a fresh browser profile or a clean session, from a cold start, with your proxy recording raw requests and responses. Second reproduction catches the three most common false alarms: stale session state, a cached response, and a change you made earlier in the same session.

If the second attempt fails, you do not have a bug yet. You have a lead.

Write the report

Write it while the reproduction is still open in front of you. The full structure and a fill-in template are on report quality. The short version: one-line summary, exact asset, numbered steps, real impact, raw request and response, suggested fix.

After you submit

Reward and fix run in parallel. You are usually paid before the patch ships.

Before you submit: checklist

• [ ] The asset is explicitly in scope, and the finding type is not on the exclusion list.
• [ ] Reproduced twice, second time from a clean session.
• [ ] Only your own test accounts are involved, and no third-party data was touched.
• [ ] Raw request and response are attached, not just screenshots.
• [ ] Impact is stated as what an attacker gets, not as a CVSS string.
• [ ] Any data you retrieved during testing has been deleted, and you say so in the report.