Belajar Web3 - Keamanan DApp & Wallet

#Pendahuluan

Setelah di episode 15 infrastruktur rapi, pada episode ini kita membahas hal yang paling sering merugikan user: keamanan. Pada 2025, kerugian exploit diperkirakan mencapai $3-4 miliar — dan sebagian besar bukan karena math kripto yang retak, melainkan kesalahan desain, kecerobohan key, dan phishing signature.

Mengapa episode ini penting? Karena sebagai developer DApp, kalian memegang tanggung jawab ganda: melindungi kode kalian (kontrak, dependency, env) dan melindungi user (dari phishing yang menyamar sebagai DApp kalian). Keamanan bukan fitur tambahan — ini prasyarat produksi.

#Melindungi Private Key

Aturan pertama yang tidak bisa ditawar:

• Private key tidak pernah masuk kode, bundle frontend, repositori, atau env yang dikirim ke browser.
• Apa pun yang ada di import.meta.env di frontend terlihat publik — hanya boleh berisi key yang memang publik (RPC key, project ID).
• Key pengirim transaksi (jika DApp punya backend relayer) hidup di server/env terenkripsi, tidak pernah di sisi client.

VITE_ALCHEMY_KEY=xxxx # publik, boleh di bundle
VITE_WC_PROJECT_ID=xxxx # publik, boleh di bundle
SERVER_SIGNER_PRIVATE_KEY=xxxx # RAHASIA — hanya di server

Perhatikan pola VITE_ (terlihat client) vs SERVER_ (hanya server). Campur keduanya adalah kesalahan klasik yang membuat key bocor ke bundle publik.

#Phishing Signature

Ancaman nomor satu wallet user. Modus: attacker meminta user menandatangani data atau transaksi yang terlihat tidak berbahaya — misalnya "claim airdrop" — padahal signature tersebut memberi kontrol atas aset.

Protection yang harus DApp kalian terapkan:

1. Tampilkan detail transaksi yang jelas — apa yang disetujui, berapa banyak, ke alamat apa.
2. Never blind-sign — pastikan kalian tidak meminta user menandatangani payload acak tanpa konteks.
3. Gunakan typed data (EIP-712) untuk pesan terstruktur yang bisa diverifikasi & divisualisasikan wallet.
4. Verifikasi domain — phisher sering memakai nama mirip; DApp asli harus membantu user mengenali domainnya.

#Approve Spending: Batasi & Revoke

Ketika user approve token (episode 11), mereka memberi kontrak hak mengambil token dalam jumlah tertentu. Risiko: jika kontrak itu ternyata jahat atau diretas, dana bisa ditarik.

Best practice yang harus DApp kalian dorong:

• Approval sebesar kebutuhan — bukan maxUint256 tanpa alasan.
• Setelah selesai, approve ulang ke 0 atau revoke.
• Tampilkan allowance saat ini sebelum meminta approve tambahan.

Revoke tool standar: revoke.cash — mendeteksi allowance yang tersisa dan memungkinkan mencabutnya. Sebagai developer, pastikan UI kalian tidak pernah "memaksa" user memberikan approval tanpa batas.

#Verifikasi Source Contract

User perlu bisa memeriksa bahwa DApp berjalan di kontrak yang benar. Ini dilakukan dengan:

• Verifikasi source di explorer (episode 8) — source terlihat & cocok dengan bytecode.
• Menampilkan address kontrak yang jelas di frontend, cross-check dengan explorer.
• Mengikuti proxies dengan transparansi: untuk upgradeable contract, pastikan implementation yang dipakai dapat diverifikasi.

#Audit Dependency

Kode kalian tidak hanya kontrak — dependency frontend/backend juga target:

npm audit
bun audit

Gunakan tool SCA (Software Composition Analysis), pin versi, dan waspada pada paket typosquatting (nama mirip paket populer). Untuk kontrak, audit pihak ketiga wajib sebelum dana produksi masuk — kerugian exploit $3-4B per tahun membuktikan alasannya.

#Nonce dan Replay Protection

• Nonce (episode 4) mencegah transaksi diputar ulang dalam chain yang sama.
• chainId mencegah replay lintas chain — itulah mengapa transaksi selalu membawa chain id.
• Untuk backend relayer, jangan pernah membiarkan nonce bocor atau dipakai ulang; simpan state nonce secara aman dan atomik.

#Ringkasan Konsep

Rangkuman yang sudah kalian pelajari di episode 16:

• Private key hanya di server env; VITE_ hanya untuk key publik.
• Phishing signature adalah ancaman utama — tampilkan detail, pakai EIP-712.
• Approval: batasi jumlah, tampilkan allowance, dorong revoke (revoke.cash).
• Verifikasi kontrak, audit dependency, dan lindungi nonce/replay.

#Penutup

Inti yang harus dibawa pulang:

• Keamanan dimulai dari memisahkan key rahasia dan publik secara tegas.
• Desain UX approval yang jujur — jangan sembunyikan detail di balik tombol.
• Kontrak produksi wajib diaudit; dependency wajib dipindai.

Di episode 17 selanjutnya, kita membahas account abstraction & smart wallets (EIP-4337) — UserOperation, EntryPoint, bundlers dan paymasters, fitur social recovery, passkey login, gasless transaction, dan spending limits yang menjadi pintu menuju ratusan juta user baru. Sampai jumpa di episode 17!