Kenapa Mobile Client Gak Bisa Dipercaya?

Ketika kita membangun sebuah aplikasi mobile, sering kali fokus kita lebih banyak tertuju pada fitur, UI/UX, atau performa. Namun ada satu hal penting yang kadang terlewat: keselamatan lingkungan tempat aplikasi itu berjalan. Berbeda dengan server yang bisa kita kontrol sepenuhnya, aplikasi mobile justru berjalan di perangkat pengguna—sebuah lingkungan yang sifatnya tidak bisa dipercaya.

Kenapa begitu? Karena di perangkat tersebut, pengguna (atau penyerang) punya kendali penuh. Mereka bisa mengutak-atik sistem operasi, memasang tools untuk debugging, bahkan melakukan reverse engineering terhadap aplikasi. Artinya, apa pun mekanisme keamanan yang hanya mengandalkan sisi client, pada akhirnya tetap bisa dilewati.

Inilah alasan kenapa para praktisi keamanan, termasuk yang dibahas oleh Muhammad Ahda Nasrullah dalam postingannya, selalu menekankan:
👉 “Jangan pernah percaya pada mobile client.”

Di artikel ini, kita akan membahas alasan kenapa mobile client dianggap tidak aman, kesalahan asumsi yang sering dibuat developer, prinsip keamanan yang benar, hingga contoh nyata bagaimana sebuah OTP bisa dibypass hanya karena validasi dilakukan di sisi aplikasi.

Kenapa Mobile Client Tidak Pernah Dianggap Aman

Satu hal mendasar dalam dunia keamanan aplikasi adalah memahami bahwa mobile client berjalan di lingkungan yang sepenuhnya berada di luar kendali kita. Berbeda dengan server yang bisa kita atur, awasi, dan proteksi, aplikasi mobile ada di perangkat pengguna—dan perangkat itu bisa dimodifikasi sesuka hati.

Pada titik ini, mindset yang perlu kita tanamkan adalah:
👉 Anggaplah client sudah diretas sejak awal.

1. Mobile Berjalan di “Hostile Environment”

Aplikasi mobile bekerja di perangkat milik pengguna. Kita tidak bisa memastikan apakah perangkat itu aman, sudah di-root, menggunakan custom ROM, atau dipasang tools khusus seperti Frida dan Objection. Bahkan tanpa root sekalipun, banyak teknik yang memungkinkan penyerang menganalisis aplikasi dari berbagai sisi.

Dengan kontrol penuh terhadap perangkat, penyerang bisa melakukan apa pun yang ia mau.

Attacker Dapat Mengontrol Client Sepenuhnya

Ketika seseorang memiliki akses langsung ke device, maka batasannya hampir tidak ada. Beberapa hal yang mungkin dilakukan penyerang antara lain:

• Membaca memori aplikasi untuk mencuri token, session ID, atau secret key.

• Memodifikasi kode agar dapat melewati validasi tertentu.

• Menyadap dan mengubah traffic jaringan, bahkan sebelum sampai ke server.

• Meng-hook fungsi aplikasi, termasuk API call, verifikasi, atau enkripsi.

• Reverse engineering untuk memahami logika bisnis aplikasi.

Hal ini berlaku bahkan pada perangkat yang tidak di-root, karena tools modern sudah sangat canggih dan mudah digunakan.

Kesalahan Asumsi yang Sering Dilakukan Developer

Banyak developer mobile masih membuat asumsi yang keliru—dan ini berdampak fatal bagi keamanan aplikasi.

❌ “Kode saya aman karena berada di APK / IPA”

Kenyataannya, hampir semua aplikasi bisa didecompile dengan mudah. Tidak ada yang benar-benar “tertutup”.

❌ “Saya bisa memverifikasi device pengguna”

Device ID atau signature apa pun bisa ditangkap, dipalsukan, atau direplay dengan tools tertentu.

❌ “Integrity check cukup untuk menghentikan modifikasi”

Sayangnya, tidak. Karena check tersebut juga berjalan di dalam device yang sama—yang bisa dimodifikasi pula.

❌ “Data sudah terenkripsi, pasti aman”

Enkripsi pun tidak ada artinya jika key-nya disimpan di dalam aplikasi, karena key tersebut dapat diambil melalui reverse engineering atau memory inspection.

Asumsi yang Tepat dalam Membangun Aplikasi Mobile

Agar aplikasi mobile tetap aman, kita harus mengubah cara pandang.

✔ 1. Anggap Client Selalu Kompromi

• Jangan percaya data apa pun dari client.

• Selalu lakukan validasi di server.

• Jangan letakkan secret penting di aplikasi.

• Jangan biarkan client membuat keputusan keamanan.

✔ 2. Server adalah Sumber Kebenaran

Semua keputusan penting harus dilakukan di backend:

• Hak akses pengguna

• Logika bisnis

• Validasi data

• Rate limiting

• Verifikasi transaksi

Server adalah satu-satunya tempat yang bisa kita kontrol sepenuhnya.

✔ 3. Defense in Depth

Kita tidak bisa mencegah serangan 100%, tetapi kita bisa memperlambatnya:

• Gunakan layers of defense

• Tambahkan monitoring dari sisi server

• Gunakan obfuscation sebagai penghambat, bukan solusi

• Rancang mekanisme untuk “gagal dengan aman” (graceful failure)

✔ 4. Server Harus Mengambil Keputusan Keamanan

Perbedaan paling jelas bisa dilihat dari contoh berikut:

❌ Buruk: Server hanya mengembalikan {valid: true/false}, lalu client memutuskan.
✔ Baik: Server memvalidasi, lalu hanya memberikan token jika valid.

Contoh Real: Bypass OTP dengan Sangat Mudah

Contoh klasik yang sering terjadi:

❌ Alur OTP Tidak Aman

1. Pengguna memasukkan OTP.

2. Client mengirim {otp: "123456"} ke backend.

3. Backend merespons {valid: false}.

4. Client mengecek nilai valid untuk menentukan “boleh lanjut atau tidak”.

Masalahnya:
Penyerang hanya perlu memodifikasi response dari server menggunakan proxy (misalnya Burp Suite atau mitmproxy) menjadi:

Dan aplikasi akan mengizinkan akses tanpa OTP yang benar.

✔ Alur OTP yang Aman

1. Pengguna memasukkan OTP.

2. Client mengirim ke backend.

3. Backend memvalidasi OTP secara internal.

4. Jika valid → server membuat session dan mengirim token ke client.

5. Jika tidak valid → server mengembalikan error tanpa token.

6. Semua request berikutnya harus menyertakan token valid.

Dengan cara ini, penyerang tidak bisa memalsukan keputusan, karena client bukan pihak yang menentukan apa pun.

Kesimpulan

• Keamanan aplikasi mobile tidak boleh bertumpu pada client.

• Client-side protections seperti obfuscation penting, tetapi hanya sebagai “penghalang”.

• Backend adalah benteng utama yang menentukan validasi, otorisasi, dan logika bisnis.

• Dengan asumsi bahwa client selalu bisa diserang, kita dapat membangun arsitektur yang jauh lebih aman dan tahan terhadap berbagai teknik manipulasi.