Banyak orang mau mulai bug bounty di Shopify karena programnya besar, bayarannya jelas, dan dokumentasinya rapi. Masalahnya, mayoritas pemula submit report pertama mereka di area yang udah pasti ditolak. Hasilnya: report dapat N/A, reputasi di HackerOne turun, dan semangat ikut turun. Gue udah lihat pola ini berulang di komunitas — orang excited, submit XSS di store sendiri, kena N/A, nyerah.
Artikel ini ngasih jalur yang realistis — dari nol sampai submit report pertama yang punya peluang nyata diterima. Fokusnya bukan ngejar jackpot, tapi dapat accepted report pertama buat naikin signal.
Kenapa Shopify cocok buat bug pertama
Shopify salah satu program paling matang di HackerOne. Policy-nya transparan, ada daftar Known Issues resmi, dan scope-nya luas: admin.shopify.com, accounts.shopify.com, partners.shopify.com, app framework, sampai Shop App. Yang penting buat pemula: kamu bisa bikin dev store gratis untuk testing sendiri, jadi nggak perlu nyentuh data orang lain.
Tapi “matang” juga artinya banyak low-hanging fruit udah habis. Jadi kamu harus main pintar, bukan main banyak.
| Faktor | Kenapa bagus buat pemula |
|---|---|
| Known Issues publik | Kamu tahu persis apa yang pasti N/A |
| Dev store gratis | Lab legal tanpa risiko langgar aturan |
| Precedent payout transparan | Bisa belajar dari disclosed report nyata |
| Scope luas | Banyak permukaan, nggak cepat jenuh |
| Tier kecil tersedia | Staff permission $50–$500 realistis buat mulai |
Langkah 1 — Daftar HackerOne dan baca policy dulu
Buat akun HackerOne, lengkapi profil, aktifkan email alias (<username>@wearehackerone.com), lalu masuk ke program Shopify. Jangan langsung testing. Baca halaman criteria dan FAQ sampai habis. Dua hal yang wajib kamu catat:
- Kamu cuma boleh test store yang dibuat dengan email format
<username>@wearehackerone.com. Menyentuh store orang lain = langsung banned. - Dilarang pakai scanner komersial (Nessus dkk), dilarang kontak Shopify Support soal bounty, dan jangan disclose sebelum resolved.
Melanggar salah satu aturan ini bisa bikin akun kamu didiskualifikasi sebelum sempat dapat bounty pertama. Serius, baca policy dulu.
Langkah 2 — Pahami area yang paling sering dibayar
Dari riset report yang udah disclosed, pola bug yang paling konsisten diterima di Shopify ada empat. Ini tabelnya lengkap dengan contoh nyata:
| Kategori | Contoh disclosed report | Payout | Kesulitan |
|---|---|---|---|
| Auth bypass / ATO di Shopify ID | Email confirmation chain (#791775) | $37.500 | Sangat tinggi |
| IDOR GraphQL antar-shop | BillingDocumentDownload (#2207248) | $5.000 | Menengah |
| Login throttle bypass + impact | Storefront API normalization (#1363672) | $3.500 | Menengah |
| Staff permission boundary | Payments balance via GraphQL (#417170) | $50–$500 | Rendah-menengah |
Buat report pertama, staff permission boundary dan IDOR GraphQL antar-shop adalah sweet spot: lebih mungkin diterima daripada ngejar ATO yang kompetisinya brutal. Mulai dari yang kesulitannya rendah-menengah, baru naik.
Langkah 3 — Setup dev store dan staff account
Bikin dev store pakai email HackerOne kamu. Lalu bikin staff account kedua dengan permission seminimal mungkin. Kenapa? Karena banyak bug permission-boundary ketemu dengan cara: login sebagai staff low-permission, lalu coba akses operation yang harusnya cuma bisa diakses owner atau staff dengan Sensitive Permission.
Langkah ringkasnya:
- Buat dev store dari Partner/Dev Dashboard (email
@wearehackerone.com). - Isi data dummy: beberapa produk, customer, draft order, discount.
- Settings → Users and permissions → Add staff, kasih permission minimal.
- Buka browser kedua (atau incognito), login sebagai staff itu.
- Siapkan juga akun owner di browser pertama untuk pembanding.
Kalau kamu belum pernah setup dev store, baca dulu Setup Shopify Dev Store untuk Security Testing — di sana ada langkah lengkap dari Dev Dashboard sampai konfigurasi test gateway.
Langkah 4 — Mapping GraphQL operations
Shopify Admin jalan di atas GraphQL. Buka Network tab browser saat kamu pakai admin normal, dan catat semua operation yang lewat. Yang kamu cari:
- Operation yang menerima ID numerik (invoice, metafield, timeline note, draft order, billing).
- Operation yang mengembalikan data sensitif (PII, finansial, payment).
Contoh query yang bisa kamu uji manual lewat tool seperti GraphiQL atau Burp Repeater (di dev store sendiri):
# Uji apakah staff low-permission bisa baca field yang
# seharusnya butuh "Manage Payments"
query {
shop {
name
# operation payments/balance yang kamu temukan di Network tab
}
}
Setelah punya daftar operation-nya, uji dua hal:
- Swap ID ke objek yang bukan milik store kamu — kalau datanya balik, itu IDOR.
- Jalankan operation sebagai staff low-permission — kalau tetap jalan padahal harusnya butuh permission, itu boundary violation.
Teknik ini dibahas lebih dalam di Shopify GraphQL Security Testing: IDOR dan Permission.
Langkah 5 — Tulis report yang nggak kena downgrade
Report yang diterima tapi dibayar kecil biasanya karena impact-nya nggak di-escalate. Rumus sederhananya:
Anomali kecil → tunjukkan jalur ke data PII atau dampak finansial nyata.
Kasus $37.500 (#791775) itu bukan karena bug-nya rumit, tapi karena hunter menunjukkan “email verify aneh” bisa berujung full ATO. Template report yang solid:
## Summary
[Apa bug-nya + dampaknya dalam satu kalimat]
## Steps to Reproduce
1. [langkah pertama, dari nol]
2. [langkah kedua, dengan query/request lengkap]
3. [observasi hasil yang membuktikan bug]
## Impact
[Data apa yang bocor/berubah, dan konsekuensi bisnisnya secara eksplisit]
## Proof of Concept
[Screenshot/video — SENSOR PII pihak lain]
## Suggested Remediation
[Saran perbaikan singkat — bonus poin, bikin triager senang]
Langkah 6 — Sabar dengan timeline
Dari pengalaman hunter lain, Shopify butuh 15–47 hari dari triage sampai keputusan bounty. Itu normal. Jangan spam, jangan kontak support, jangan panik. Pakai waktu nunggu buat hunting target berikutnya.
Common mistakes yang bikin report pertama gagal
Ini kesalahan yang paling sering, dan bikin report pertama kena N/A:
- Lapor XSS di store sendiri / storefront. Known Issue. Pasti N/A.
- Lapor user/store name enumeration. Jebakan nomor satu pemula — Known Issue.
- Lapor missing rate limit tanpa impact. Harus tunjukin brute force beneran berhasil.
- Nganggep admin lihat data staff = IDOR. Itu intended, admin otoritas atas staff org-nya.
- Submit UUID IDOR tanpa jalur akses realistis. Shopify nggak opt-in standar UUID IDOR.
- Berhenti di anomali, nggak escalate impact. Accepted tapi dibayar receh atau malah Informative.
Daftar lengkap penyebab N/A ada di 7 Alasan Report Bug Bounty Kamu Dapat N/A — wajib baca sebelum submit. Dan karena akun baru punya kesempatan terbatas, pahami juga mekanika trial report & signal.
Checklist sebelum submit report pertama
- Target ada di area peluang-tinggi (staff permission / IDOR numerik), bukan ATO.
- Bug TIDAK ada di daftar Known Issues.
- TIDAK ada disclosed report duplikat.
- Testing 100% di dev store milik sendiri (email
@wearehackerone.com). - Impact sudah di-escalate ke PII / finansial.
- Steps to reproduce lengkap, bisa diikuti dari nol.
- PoC ada, PII pihak lain disensor.
- Tidak pakai scanner komersial, tidak kontak Support.
Mau shortcut?
Kalau kamu mau skip fase riset berminggu-minggu dan langsung punya checklist area testing, daftar Known Issues yang udah dikurasi, serta template report, gue sama tim bundel semuanya di Shopify Bug Bounty Starter Pack seharga $1. Isinya hasil riset dari puluhan disclosed report — hemat waktu riset manual kamu yang bisa makan berhari-hari.
Report pertama memang yang paling susah. Tapi kalau kamu mulai dari area yang benar dan menghindari jebakan N/A, peluang kamu jauh lebih tinggi daripada mayoritas pemula yang asal submit.
Sumber & referensi
- Shopify Bug Bounty Program & criteria: hackerone.com/shopify
- “Hacking GraphQL at Shopify” — Shopify Engineering
- Disclosed reports: #791775 (ATO $37.500), #2207248 (IDOR $5.000), #1363672 (throttle bypass $3.500), #417170 (staff permission)
- HackerOne docs — Signal & Reputation: docs.hackerone.com