Hardening Aplikasi React Native: Bukan Hanya JailMonkey

Saya menulis ini sebagai Senior Mobile Engineer dengan pengalaman 5+ tahun membangun produk React Native di fintech P2P lending dan aplikasi asuransi untuk customer.

Pada fase awal hardening, tim kami pernah mengandalkan jail-monkey sebagai gerbang utama keamanan. Secara teori terlihat aman, tetapi saat diuji di perangkat yang benar-benar hostile, pendekatan itu tidak bertahan lama.

Pengalaman Nyata di Lapangan

Dalam beberapa investigasi insiden yang saya tangani langsung, pola masalahnya berulang:

• Bypass cepat dengan Frida: flag root/hook bisa dipaksa selalu false.
• False positive pada user valid: perangkat Android enterprise tertentu terdeteksi berisiko padahal legal.
• Replay request masih lolos: request sensitif yang sudah pernah valid bisa diputar ulang jika backend lemah.
• Logika keamanan terlalu dekat ke UI: keputusan krusial terjadi di JavaScript, bukan di server yang tepercaya.

Kesimpulan praktisnya: sinyal dari sisi klien adalah telemetry, bukan otoritas keamanan.

Analisis Teknis: Kenapa Cek Root/Hook Tidak Bisa Jadi Penentu Final

Aplikasi React Native berjalan di proses yang dikuasai pemilik perangkat. Artinya, penyerang yang punya kapabilitas bisa:

• Melakukan instrumentasi runtime untuk mengubah output metode.
• Memodifikasi alur JavaScript agar validasi dilompati.
• Menjalankan ulang request API di luar alur UI aplikasi.

Contoh pola yang sering terlihat aman, tetapi rapuh:

import JailMonkey from "jail-monkey";

export function getDeviceRiskSignal() {
  return {
    isJailBroken: JailMonkey.isJailBroken(),
    isDebuggedMode: JailMonkey.isDebuggedMode(),
    hookDetected: JailMonkey.hookDetected(),
  };
}

Jika aksi bernilai tinggi hanya bergantung pada boolean ini, penyerang cukup menguasai satu layer klien untuk menang.

Strategi Hardening yang Lebih Tahan Serangan

Setelah beberapa iterasi gagal di pendekatan client-only, saya memindahkan enforcement ke backend.

Integritas Device/App Harus Diverifikasi Server

Di Android, kami memverifikasi token integritas dari Play Integrity API di backend, dan di iOS kami memverifikasi assertion dari App Attest di backend sebelum konteks request dianggap layak dipercaya. Attestation kami perlakukan sebagai salah satu faktor dalam risk scoring, bukan sebagai sumber kebenaran absolut, sehingga keputusan akhir tetap bergantung pada kontrol server-side lain yang saling menguatkan.

Hardening Jalur Transport

Kami menerapkan konfigurasi TLS modern sebagai baseline, menggunakan certificate atau public key pinning secara selektif pada alur berisiko tinggi, lalu memantau kegagalan pin secara berkelanjutan dengan rencana rotasi yang teruji agar pembaruan sertifikat tidak memutus trafik produksi.

Desain API Anti-Replay

Untuk aksi sensitif, kami mewajibkan nonce sekali pakai atau idempotency key, mengikat token tersebut ke konteks user, session, dan device, lalu menerapkan masa berlaku yang singkat serta penolakan ketat terhadap token duplikat agar request yang tertangkap tidak bisa diputar ulang dengan sukses.

Otorisasi Tetap Diputuskan Server

Kami menempatkan transaksi uang, klaim promo, dan perubahan privilege sepenuhnya di bawah kebijakan server-side, sementara sinyal risiko dari klien hanya diperlakukan sebagai input pendukung untuk memperkaya konteks keputusan, bukan sebagai kriteria otorisasi tunggal.

Referensi Otoritatif yang Saya Jadikan Baseline

• React Native docs: Security
• OWASP: MASVS dan MASTG
• Google: Play Integrity API
• Apple: App Attest
• IETF: RFC 8446 (TLS 1.3)

Referensi ini penting agar keputusan teknis tidak bergantung pada asumsi internal yang sulit diaudit.

Trustworthiness: Risiko dan Keterbatasan yang Harus Diakui

Pendekatan ini kuat, tetapi tetap memiliki biaya dan batasan nyata: ketersediaan layanan attestation dapat terganggu sehingga backend wajib memiliki fail-safe yang rasional, proses certificate pinning membawa risiko operasional saat rotasi tidak disiplin, risk scoring yang terlalu ketat dapat memicu false positive untuk user valid, dan seluruh kontrol ini menambah beban maintenance karena rule fraud, validasi nonce, serta observability perlu dituning secara berkala.

Tidak ada arsitektur yang benar-benar kebal. Target realistisnya adalah menaikkan biaya serangan, menurunkan keberhasilan bypass trivial, dan menjaga UX tetap masuk akal.

Pelajaran Berharga

Cek sisi klien sebaiknya diposisikan sebagai indikator kebisingan, bukan keputusan final, sementara keputusan keamanan untuk aset bernilai tinggi wajib dipindahkan ke server; dari pengalaman implementasi, simulasi red-team jauh lebih jujur dibanding klaim dari checklist statis, dan replay protection yang benar biasanya memberi dampak lebih besar dibanding menambah satu library deteksi baru di klien.

Tips dari Lapangan

Mulailah dari satu endpoint paling kritis, misalnya payout atau klaim promo, lalu terapkan nonce, idempotency, dan verifikasi attestation terlebih dahulu pada endpoint tersebut; sejak awal, catat alasan penolakan request secara terstruktur agar tim fraud dan engineering menilai bukti yang sama, kemudian jalankan exercise bypass bulanan menggunakan rooted atau jailbroken device dengan skrip Frida untuk memastikan kontrol tetap relevan terhadap pola serangan terbaru.

Dari pengalaman saya, perubahan ini tidak menghilangkan serangan sepenuhnya, tetapi membuat bypass sederhana tidak lagi cukup untuk mengeksekusi aksi sensitif.