Hard-reject API key dengan izin withdraw: deep-dive teknis

Sebagian besar platform trading menerima API key dengan izin withdraw yang diaktifkan. Mereka menampilkan banner peringatan kuning, meminta Anda mengetik "I understand", dan tetap menyimpan key tersebut. Kami tidak melakukan itu. Jika key Anda memiliki izin withdraw, kami menolaknya saat onboarding dan tidak pernah menyimpannya. Post ini menjelaskan mengapa, bagaimana caranya, dan apa yang sebenarnya dikorbankan oleh alternatif tersebut.

Model ancaman dalam satu paragraf

Setiap sistem yang menyimpan API key dengan izin withdraw adalah satu kebocoran kredensial yang jauhnya dari mengosongkan akun user. Kebocoran tidak harus berupa pelanggaran database — bisa jadi laptop karyawan yang dikompromikan, backup yang salah konfigurasi, side-channel dalam dependensi pihak ketiga, atau dump proses-memory yang masuk ke dalam log terenkripsi. Setiap skenario itu telah terjadi pada perusahaan yang lebih besar dari kami. Satu-satunya pertahanan yang tahan lama adalah: jangan simpan key siapa pun ke dana mereka di tempat pertama.

Cara deteksi bekerja

Pada panggilan terautentikasi pertama setelah user menempel key, kami membuat panggilan introspeksi izin spesifik-pertukaran. Sebagian besar venue utama memaparkan salah satu dari:

• Endpoint "query API key info" khusus yang mengembalikan set izin sebagai field terstruktur, atau
• Endpoint informasi akun di mana scope izin key disertakan sebagai bagian dari payload respons.

Kami mencari flag apa pun yang memberikan withdraw, transfer internal, transfer sub-akun keluar, atau transfer universal keluar — venue menggunakan nama berbeda untuk ide yang sama. Jika ada yang ada, kami membuang secret di memori segera, mengembalikan error terstruktur ke UI, dan tidak pernah menulis key ke database kami.

Mengapa hard-reject daripada warn

Peringatan sering diabaikan. Kami telah mengamati data ini selama bertahun-tahun di berbagai produk. Tingkat dasar user mengetik "I understand" tanpa membaca sesuatu pun di atasnya adalah sekitar 80% atau lebih. Peringatan yang diabaikan 80% user bukanlah kontrol keamanan; itu adalah perisai tanggung jawab.

Hard rejection adalah kebalikannya. Ini menempatkan friction di tempat yang tepat: user kembali ke pertukaran, membuat key baru dengan izin trade saja, kembali, dan menempel key itu. Seluruh loop hanya menghabiskan waktu user mungkin dua menit. Itu menghabiskan penyerang — dalam skenario kebocoran kredensial terburuk — seluruh akun.

Apa yang sebenarnya dikorbankan path warn-instead-of-reject

Pola warn-and-store terlihat user-friendly sampai Anda bertanya: apa yang terburuk terlihat seperti? Anda mendapatkan satu karyawan bermusuhan, satu kompromi rantai pasokan, satu side-channel dalam dependensi transitif, satu log mis-scoped, dan jawabannya adalah bahwa key dengan izin withdraw sama baiknya dengan orang terlemah dan potongan kode terlemah yang pernah menyentuhnya.

Hard-rejecting membalik kalkulus itu. Bahkan dalam kompromi database penuh terburuk, penyerang pergi dengan key read+trade. Key trade-only dapat menimbulkan kerusakan — mereka dapat meledakkan posisi, churn fees, membuang posisi terbuka ke pasangan illiquid — tetapi mereka tidak dapat withdraw. Dana tetap di pertukaran. Itu bukan risiko nol, tetapi itu adalah risiko yang Anda setujui ketika Anda menghubungkan agen trading otomatis di tempat pertama.

Apa yang masih tidak dapat kami pertahankan

Kami tidak berpura-pura hard rejection adalah postur keamanan yang lengkap. Itu adalah satu kontrol. Set lengkap didokumentasikan di halaman keamanan kami: enkripsi amplop KMS dengan key data per-user, secret yang didekripsi yang hanya ada dalam memori proses dan hanya untuk durasi panggilan API, log audit terrangkai hash append-only, isolasi lintas-user yang diuji CI, dan program pengungkapan kerentanan. Hard-rejecting izin withdraw hanya merupakan bagian paling terlihat dari stack itu — dan yang paling mudah untuk Anda verifikasi sendiri, karena Anda dapat menonton kami menolak key dengan izin withdraw secara real-time selama onboarding.