N/A (Not Applicable) adalah mimpi buruk hunter pemula. Report ditutup tanpa bounty, dan reputasi di HackerOne kena. Yang bikin frustrasi: mayoritas N/A sebenarnya bisa dihindari kalau kamu tahu aturan mainnya sebelum submit. Ini yang kejadian pas gue iseng ngelihat disclosed report yang di-N/A — polanya itu-itu lagi, hal yang udah jelas tertulis di policy tapi tetap dilaporin.
Artikel ini ngerangkum 7 penyebab N/A paling umum di program Shopify, langsung dari policy resmi dan pola disclosed report. Hafalin, dan kamu udah selangkah di depan mayoritas pemula.
Kenapa N/A itu mahal (bukan cuma “nggak dibayar”)
N/A bukan sekadar “report ditolak”. Dampaknya ke signal kamu:
| Outcome | Dampak signal | Dampak akun |
|---|---|---|
| Resolved / Triaged | Naik | Akun sehat, invite private |
| Informative | Netral–negatif | Stagnan |
| N/A | Turun | Akun baru bisa kena throttle |
| Spam | Turun drastis | Bahaya ban |
Buat akun baru yang masih punya sedikit kesempatan (baca HackerOne Trial Reports), satu N/A bisa ngerusak rata-rata signal yang masih rapuh. Jadi menghindari N/A itu bukan soal gengsi — itu soal menjaga akun kamu tetap bisa jalan.
1. Kamu lapor sesuatu di daftar Known Issues
Shopify punya daftar Known Issues resmi. Apa pun yang ada di situ = pasti N/A. Yang paling sering jadi jebakan:
- XSS di storefront store sendiri, XSS di iframe Theme Editor, XSS di Rich Text Editor legacy, XSS di CDN domain.
- Arbitrary file upload ke CDN.
- CSRF modify cart, CSRF login/logout (kecuali di-chain jadi impact lebih besar).
- Staff access ke
/admin/settings/shop.json,account.json,users.json,locations.json— ini intentional. - Password reset token tidak expire saat ganti email; email change tanpa verifikasi.
- “Opening Soon” password insecure, Stocky permission issues, Order Printer sanitization bypass.
- CSV/formula injection, tab nabbing, SPF/DKIM/DMARC issues, hyperlink injection.
- POS PIN bruteforce, mobile biometrics bypass, lack of SSL pinning.
Cara hindari: baca daftar Known Issues sampai hafal sebelum testing. Jangan buang satu pun kesempatan trial report kamu untuk hal yang udah ada di daftar ini.
2. User atau store name enumeration
Ini jebakan klasik. Kamu nemu endpoint yang balikin respons beda untuk user yang ada vs tidak ada, lalu kamu pikir itu bug. Di Shopify, enumeration user/store name adalah Known Issue — otomatis N/A. Rasanya seperti bug, tapi bukan.
Kenapa ini sering kejebak? Karena di banyak program lain, enumeration memang dihargai. Tapi tiap program beda. Jangan bawa asumsi dari program A ke program B.
3. Missing rate limit tanpa demonstrasi impact
“Endpoint ini bisa di-brute force” bukan report yang valid. Policy Shopify eksplisit menyebut “bruteforcing without demonstrating impact” sebagai ineligible. Kalau kamu mau melaporkan rate limit, kamu harus tunjukkan dampak nyatanya — misal berhasil ambil alih akun, bukan sekadar “bisa dikirim 1000 request”.
Pengecualian menarik yang membuktikan poin ini: ada kasus login throttling bypass yang dibayar $3.500 (report #1363672) karena hunter menunjukkan normalisasi email tidak konsisten (tambah whitespace / ubah kapitalisasi bypass rate limit) dan mendemonstrasikan credential brute force yang berhasil. Bedanya cuma satu: impact yang didemonstrasikan.
| Report rate limit | Hasil |
|---|---|
| “Endpoint X nggak ada rate limit” | N/A |
| “Endpoint X nggak ada rate limit, ini 1000 request berhasil” | Masih N/A (belum ada impact) |
| “Normalisasi email bypass throttle → brute force kredensial berhasil, ini buktinya” | $3.500 |
4. Admin-vs-staff dalam organisasi yang sama
Ini kesalahpahaman trust boundary yang paling sering. Kamu kasih staff permission minimal, lalu admin store bisa lihat data staff itu — kamu pikir itu IDOR. Bukan. Admin memang punya otoritas atas staff di organisasinya. IDOR yang valid harus cross-organizational (org A akses data org B) atau privilege escalation nyata melewati permission model.
Shopify secara eksplisit menjawab ini ke hunter pemula: akses admin ke record staff di org yang sama = expected functionality. Aturan simpelnya:
Valid: staff/attacker di org A mengakses data org B, atau staff eskalasi melewati permission-nya sendiri. N/A: admin mengakses data staff-nya sendiri di org yang sama.
5. UUID IDOR tanpa jalur akses realistis
Shopify tidak opt-in ke standar UUID IDOR HackerOne. Artinya kalau kamu nemu object pakai UUID dan klaim “ini bisa IDOR”, itu nggak otomatis dibayar. UUID pada dasarnya nggak bisa ditebak, jadi kamu harus tunjukkan jalur akses nyata ke UUID tersebut (misal bocor di response lain). Tanpa itu, N/A.
Fokus kamu lebih baik di ID numerik/incremental yang bisa di-enumerate. Contoh yang dibayar: billing document ID numerik yang bisa di-increment (#2207248, $5.000). Teknik lengkapnya ada di Shopify GraphQL Security Testing: IDOR dan Permission.
6. Ineligible vulnerability types
Beberapa kategori memang nggak akan pernah dibayar, apa pun kualitas report-nya:
- DDoS, content spoofing, social engineering, email flooding.
- Open redirect tanpa user interaction dan tanpa chain. (Catatan: ada hunter yang upgrade open redirect jadi XSS via
javascript:URI dan dibayar $1.750 — kuncinya di chain.) - HTML injection di email tanpa chain, SSRF yang cuma HTTP/DNS interaction, GraphQL introspection (intentional), password complexity, CVV validation.
- Race condition yang cuma bypass fitur berbayar di plan ineligible.
- Bug di third-party apps — kamu harus lapor ke developer dulu, dan tetap nggak dibayar Shopify.
Pola yang jelas: bug tanpa chain ke impact nyata = ineligible. Open redirect sendirian = N/A; open redirect yang di-chain jadi XSS = dibayar. Selalu tanya “ini berujung ke mana?”.
7. Session persistence dan “intended behavior”
Session yang masih aktif setelah logout? Itu intended behavior di Shopify, udah ada disclosed report yang di-N/A untuk ini. Begitu juga info disclosure yang datanya memang public-by-design. Sebelum lapor “data X bocor”, tanya dulu: apakah data ini memang sengaja publik?
Cara ngecek: baca FAQ dan criteria program. Kalau Shopify menyatakan sesuatu “by design” atau “intended”, jangan lapor meski terasa aneh.
Rangkuman 7 penyebab N/A
| # | Penyebab | Cara hindari |
|---|---|---|
| 1 | Lapor Known Issue | Hafal daftar Known Issues dulu |
| 2 | User/store enumeration | Jangan — ini Known Issue |
| 3 | Rate limit tanpa impact | Demonstrasikan brute force berhasil |
| 4 | Admin-vs-staff same org | Harus cross-org / eskalasi nyata |
| 5 | UUID IDOR tanpa jalur akses | Fokus ID numerik, atau tunjukkan leak UUID |
| 6 | Ineligible types tanpa chain | Chain ke impact nyata dulu |
| 7 | Intended behavior | Cek FAQ “by design” sebelum lapor |
Checklist anti-N/A
Sebelum submit, tanya ke diri sendiri:
- Apakah ini ada di Known Issues? (Kalau ya, stop.)
- Apakah ini enumeration / rate limit tanpa impact? (Kalau ya, escalate dulu atau stop.)
- Apakah ini cross-org atau cuma same-org? (Harus cross-org.)
- Apakah ID-nya numerik dan bisa di-enumerate? (UUID butuh jalur akses.)
- Apakah ini “intended behavior” menurut FAQ? (Kalau ya, stop.)
- Apakah aku udah tunjukkan dampak nyata ke PII / finansial?
- Apakah TIDAK ada disclosed report duplikat untuk ini?
Kalau kamu baru mau submit report pertama, baca juga Cara Dapat Bug Pertama di Shopify HackerOne biar langsung main di area yang benar. Dan kalau kamu masih bingung mulai dari mana sebagai hunter Indonesia, ada peta jalannya di Bug Bounty untuk Orang Indonesia.
Shortcut: daftar Known Issues yang udah dikurasi
Daftar Known Issues dan ineligible types Shopify tersebar di banyak halaman policy. Gue sama tim rangkum semuanya jadi satu checklist praktis — plus pola report yang terbukti diterima — di Shopify Bug Bounty Starter Pack ($1). Satu kali baca, hemat berhari-hari riset dan selamatkan trial report kamu dari N/A.
N/A bukan soal apes. Itu soal lapor hal yang udah ada di daftar “jangan lapor ini”. Hafalkan daftarnya, dan kamu udah selangkah di depan mayoritas pemula.
Sumber & referensi
- Shopify Bug Bounty Program — policy, criteria, Known Issues: hackerone.com/shopify
- Disclosed reports: #1363672 (throttle bypass $3.500), #2207248 (billing IDOR $5.000)
- HackerOne docs — Signal & Reputation: docs.hackerone.com