HackerOne Trial Reports: Cara Gak Buang 6 Kesempatan

Akun HackerOne baru nggak bisa langsung spam report ke mana-mana. Platform membatasi kamu dengan trial report dan sistem signal/reputation. Buat pemula, ini terasa seperti kungkungan — “kok gue dibatasin padahal belum ngapa-ngapain?” Padahal ini justru mekanisme yang melindungi kamu dari menghancurkan reputasi sendiri sebelum sempat mulai.

Ini yang kejadian pas orang nggak ngerti sistem ini: mereka submit 6 report asal-asalan di minggu pertama, 5 kena N/A, dan tiba-tiba signal mereka jeblok ke negatif. Akun yang baru umur seminggu udah “rusak”. Artikel ini menjelaskan cara kerja signal dan strategi memaksimalkan setiap kesempatan — khususnya buat yang mau serius di program seperti Shopify.

Apa itu signal dan kenapa penting

Setiap report yang kamu submit memengaruhi signal kamu. Signal itu semacam skor kualitas: rata-rata “seberapa valid report yang kamu kirim”. Begini pengaruh tiap outcome:

Signal rendah = akses terbatas, invite private program susah, dan di beberapa kondisi report kamu bisa di-throttle. Signal tinggi = pintu kebuka: private invites, trust lebih cepat dari triager, dan akun yang “sehat”.

Intinya: kualitas jauh lebih penting daripada kuantitas. Satu N/A bisa menghapus efek beberapa report bagus, karena signal dihitung sebagai rata-rata, bukan jumlah.

Kenapa kesempatan awal itu mahal

Saat akun masih baru, kamu belum punya track record. HackerOne membatasi berapa report yang bisa kamu submit selagi signal masih rendah — ini yang sering disebut “trial report” di komunitas. Beberapa report pertama kamu pada dasarnya adalah audisi.

Kalau kamu buang kesempatan awal untuk hal yang pasti N/A (lihat 7 Alasan Report Dapat N/A), kamu menggali lubang reputasi sebelum mulai. Dan karena rata-rata signal akun baru sangat sensitif (sampel kecil), satu N/A di awal jauh lebih nyakitin daripada satu N/A pas kamu udah punya 50 accepted report.

Bayangkan kamu cuma punya 6 peluru. Kamu nggak mau tembak 5 di antaranya ke tembok. Tiap report harus kamu perlakukan seperti kamu cuma punya sedikit kesempatan — karena memang begitu.

Strategi 1 — Jangan submit sebelum yakin

Aturan emas: submit hanya kalau kamu yakin ini bukan Known Issue dan punya impact nyata. Sebelum klik submit, jalankan checklist ini:

1. Apakah ini ada di daftar Known Issues program? (Untuk Shopify, daftarnya panjang banget.)
2. Apakah aku sudah mendemonstrasikan impact nyata, bukan cuma “berpotensi”?
3. Apakah ini cross-org / real privilege escalation, bukan behavior intended?
4. Apakah reproduksi-nya stabil dan jelas, bisa diulang dari nol?

Kalau ada satu jawaban “nggak yakin”, tahan dulu. Lebih baik report yang ketahan seminggu tapi solid, daripada report buru-buru yang kena N/A dan ngerusak signal.

Strategi 2 — Pilih target dengan boundary yang jelas

Untuk akun baru, program dengan dokumentasi scope yang rapi jauh lebih aman daripada program yang vague. Shopify salah satu yang paling transparan: ada criteria, FAQ, Known Issues, bahkan precedent payouts yang bisa kamu baca. Kamu bisa tahu persis apa yang dibayar sebelum buang satu trial report pun.

Mulai dari kategori yang peluang accepted-nya tinggi meski bayarannya kecil. Untuk Shopify, staff permission boundary ($50–$500) adalah entry point yang bagus: lebih mudah diterima daripada ATO, dan tetap menaikkan signal kamu. Detailnya di Cara Dapat Bug Pertama di Shopify HackerOne. Sebelum testing, pastikan environment-mu legal — setup di Setup Shopify Dev Store.

Strategi 3 — Tulis report yang bikin triager kerja gampang

Triager menilai banyak report tiap hari. Report yang jelas lebih cepat di-triage dan lebih kecil kemungkinan di-downgrade. Struktur report yang bagus:

## Summary
[Satu kalimat: apa bug-nya dan dampaknya.]
Contoh: Staff tanpa permission "Manage Payments" bisa membaca
saldo Shopify Payments via Admin GraphQL.

## Steps to Reproduce
1. Login sebagai staff account low-permission di dev store.
2. Jalankan operation GraphQL berikut:
   [query lengkap, bisa di-copy-paste]
3. Observasi response berisi data saldo (seharusnya butuh permission).

## Impact
Staff tanpa otorisasi finansial dapat mengakses data saldo
merchant — information disclosure finansial.

## Proof
[Screenshot/video. PII dan data pihak lain DISENSOR.]

## Suggested Fix
Validasi permission "Manage Payments" sebelum resolve field saldo.

Report yang rapi bukan cuma soal sopan santun — itu memengaruhi apakah impact kamu diakui penuh atau di-downgrade jadi low. Triager yang harus nebak-nebak maksud kamu cenderung kasih severity lebih rendah.

Strategi 4 — Escalate impact sebelum submit

Banyak report accepted tapi dibayar kecil karena hunter berhenti di “anomali”, bukan di “dampak”. Contoh paling terkenal di Shopify: chain email confirmation yang dibayar $37.500 (report #791775) — bukan karena bug-nya rumit, tapi karena hunter menunjukkan anomali kecil bisa jadi full account takeover.

Sebelum submit, tanya: “so what?”. Kalau jawabannya “ya… bisa X tapi nggak ngapa-ngapain”, cari dulu jalur ke PII atau dampak finansial. Anomali tanpa impact = Informative atau N/A. Anomali + jalur ke ATO/PII = bounty beneran.

Strategi 5 — Terima bahwa timeline itu lambat

Di Shopify, 15–47 hari dari triage ke keputusan bounty itu normal. Jangan spam komentar, jangan kontak support (di Shopify ini langsung disqualify), jangan panik. Signal kamu nggak akan turun karena menunggu. Yang turun signal itu report buruk, bukan report yang pending.

Kalau report kamu kena N/A

Jangan langsung argue agresif. Baca alasannya, pahami apakah kamu memang melanggar scope. Kalau kamu yakin triager salah, ajukan klarifikasi sopan dengan bukti tambahan — misal “berdasarkan criteria X, impact ini seharusnya masuk karena Y, berikut PoC tambahan”.

Tapi kalau memang Known Issue, terima saja dan belajar. Menyeret argumen yang kalah justru memperburuk kesan, dan triager mencatat hunter yang suka ngotot tanpa dasar.

Common mistakes yang buang trial report

1. Submit “bug” yang ternyata Known Issue. Penyebab N/A nomor satu. Hafalin daftarnya.
2. Lapor rate limit tanpa demonstrasi impact. “Bisa di-brute force” bukan bug sampai kamu tunjukin brute force-nya berhasil.
3. Salah paham trust boundary. Admin lihat data staff di org yang sama = intended, bukan IDOR.
4. Submit duplicate karena nggak cek disclosed report. Baca dulu yang udah ada.
5. Report berantakan tanpa PoC jelas. Di-downgrade, kadang di-N/A.
6. Ngegas argue pas kena N/A valid. Ngerusak hubungan sama triager.

Checklist sebelum klik “Submit”

• Sudah cek bug ini TIDAK ada di Known Issues program.
• Sudah cek TIDAK ada disclosed report duplikat.
• Impact sudah di-escalate ke PII / finansial / ATO, bukan cuma anomali.
• Ini cross-org / privilege escalation nyata, bukan behavior intended.
• Steps to reproduce bisa diikuti dari nol.
• PoC (screenshot/video) ada, PII pihak lain disensor.
• Severity yang kamu klaim realistis dan didukung bukti.
• Testing dilakukan di environment legal milik sendiri.

Maksimalkan kesempatan dengan persiapan, bukan keberuntungan

Trial report yang kebuang hampir selalu karena kurang persiapan, bukan kurang skill. Untuk mempercepat fase persiapan di Shopify, gue sama tim kumpulin checklist area testing, daftar Known Issues, pola report yang terbukti diterima, dan template report ke dalam Shopify Bug Bounty Starter Pack ($7). Tujuannya satu: biar tiap report yang kamu submit punya peluang nyata, bukan buang-buang signal.

Ingat: akun HackerOne yang sehat dibangun dari report yang dipikirkan, bukan report yang banyak. Enam kesempatan sudah cukup untuk membangun momentum — asal nggak satu pun kamu buang untuk Known Issue.

Sumber & referensi

• HackerOne — dokumentasi Signal & Reputation: docs.hackerone.com
• Shopify Bug Bounty Program & criteria (HackerOne): hackerone.com/shopify
• Disclosed report #791775 — Shopify account takeover ($37.500)