# Keamanan aplikasi mobile: persiapan rilis Android dan iOS

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Pemeriksaan aplikasi mobile mencakup data di perangkat, interaksi dengan sistem operasi, dan komunikasi ke layanan lain. Hasil pemeriksaan Android tidak otomatis mewakili iOS atau keamanan API.

URL kanonis: https://kompli.id/panduan/keamanan/keamanan-aplikasi-mobile/
Sumber diakses: 2026-09-28
Diperbarui: 2026-09-29
Penulis: Kompli
Sumber diperiksa: 2026-09-29


## Apa yang berbeda dari pengamanan website?

**Aplikasi mobile menyimpan dan memproses sebagian data di perangkat pengguna.** Tim perlu memeriksa bagian itu selain server dan API. Versi aplikasi, sistem operasi, cara masuk, izin perangkat, dan komponen tambahan dapat mengubah lingkup pemeriksaan.

OWASP MASVS, singkatan dari *Mobile Application Security Verification Standard*, menyediakan kelompok persyaratan keamanan aplikasi mobile. MASTG adalah panduan pengujiannya. Keduanya membantu menyusun pemeriksaan; menyebut MASVS dalam proposal belum membuktikan suatu aplikasi sudah diperiksa.

## Tentukan aplikasi dan versi yang dicakup

Catat Android, iOS, atau keduanya; nomor versi dan identitas paket; versi sistem operasi yang didukung; serta fitur yang diperiksa. Aplikasi yang dibuat dengan satu kerangka kerja tetap dapat berperilaku berbeda di dua platform.

Sertakan daftar API dan integrasi, akun uji tiap peran, perangkat pengujian, serta perbedaan lingkungan uji dengan produksi. Penguji mobile tidak otomatis mendapat izin menguji server pihak lain. Gunakan [panduan akses API](/panduan/keamanan/keamanan-api-akses-data/) untuk pembatasan data di backend.

## Contoh rencana pemeriksaan aplikasi dokumen

Contoh fiktif: “Berkas Tim” memungkinkan pegawai membaca dokumen dan mengunggah foto bukti. Gunakan dokumen serta akun buatan untuk membahas kriteria berikut dengan penguji.

| Bagian | Pertanyaan yang perlu dijawab | Bukti yang diminta |
| --- | --- | --- |
| Penyimpanan lokal | Data apa yang tertinggal setelah keluar akun? | Hasil pemeriksaan penyimpanan dan versi aplikasi |
| Tampilan dan notifikasi | Apakah isi dokumen muncul pada notifikasi yang tidak perlu? | Contoh tampilan dengan data fiktif |
| Izin kamera atau lokasi | Apakah fungsi utama tetap masuk akal saat izin ditolak? | Hasil alur izin diterima, ditolak, dan dicabut |
| Komunikasi | Apakah jalur ke server divalidasi dan terlindungi? | Lingkup serta hasil pemeriksaan jaringan oleh penguji |
| Akses dokumen | Dapatkah akun A membaca dokumen B? | Matriks akses aplikasi dan API, termasuk kasus penolakan |
| Pembaruan | Apa yang terjadi pada versi aplikasi lama? | Keputusan dukungan versi dan hasil pemeriksaan kompatibilitas |

Tulis hasil nyata, bukan langsung mencentang semua baris. Bedakan “lulus pada versi yang diuji”, “belum diperiksa”, dan “tidak berlaku beserta alasan”. Tabel ini bukan prosedur forensik perangkat atau bukti pentest yang telah dilakukan.

## Bagaimana menilai izin dan SDK?

SDK (*software development kit*) adalah paket komponen pengembangan. Sebagian SDK menangani analitik, notifikasi, atau fungsi lain. Inventarisasi tujuan, data yang diakses, pihak penerima, versi, serta orang yang mengurus pembaruannya.

Bandingkan perilaku aplikasi dengan kebutuhan fitur. Misalnya, aplikasi unggah foto bukti tidak otomatis memerlukan lokasi terus-menerus. Bahas izin yang diperlukan saat fungsi digunakan dan dampak ketika pengguna menolaknya. Penjelasan kepada pengguna perlu sesuai dengan perilaku aplikasi dan SDK yang sebenarnya.

Untuk dasar pemrosesan dan pemberitahuan penggunaan data, lanjutkan ke [kebijakan privasi website dan aplikasi](/panduan/pdp/kebijakan-privasi-website-aplikasi/). Izin sistem operasi bukan jawaban lengkap atas semua kewajiban PDP.

## Apa yang disiapkan untuk pentest mobile?

Sediakan paket aplikasi yang disepakati, dokumentasi fitur, akun uji, data fiktif, kontak teknis, dan batas tindakan. Pastikan laporan membedakan pemeriksaan aplikasi, API, dan komponen pihak ketiga serta mencantumkan bagian yang tidak dapat diuji.

Minta penguji menjelaskan penggunaan versi MASVS dan pengujian yang relevan. Pilihan kontrol harus sesuai risiko; satu daftar umum tidak menutup semua kebutuhan aplikasi kesehatan, pembayaran, atau perangkat yang berdampak pada keselamatan.

## Kapan keputusan rilis dibuat?

Pemilik produk, pengembang, dan penanggung jawab keamanan meninjau temuan serta batas pemeriksaan sebelum rilis. Catat perbaikan, uji ulang, dan alasan penundaan atau penerimaan risiko sesuai kewenangan.

Periksa lagi ketika fitur, SDK, alur akun, atau pemakaian data berubah. Hubungkan pekerjaan tersebut dengan [proses pengembangan yang aman](/panduan/keamanan/pengembangan-aplikasi-yang-aman/), agar pemeriksaan tidak hanya muncul menjelang tanggal peluncuran.

## Pahami risiko di balik pemeriksaan

Baca [perbandingan proyek OWASP](/panduan/owasp/top-10-asvs-wstg-masvs/) untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.
## Sumber rujukan

- [OWASP MASVS — kelompok kontrol keamanan aplikasi mobile](https://mas.owasp.org/MASVS/) — The MASVS Control Groups; penyimpanan, autentikasi, jaringan, platform, kode dan privasi
- [OWASP MASVS — penggunaan, asumsi, dan batas lingkup](https://mas.owasp.org/MASVS/03-Using_the_MASVS/) — Secure App Ecosystem; Security Knowledge and Expertise; Applicability of the MASVS

## Perlu membahas kebutuhan tim Anda?

Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=keamanan)

## Bacaan terkait

- [Keamanan API: akses pengguna, tenant, token, dan batas penggunaan](https://kompli.id/panduan/keamanan/keamanan-api-akses-data/)
- [Pengembangan aplikasi yang aman: threat modeling sampai rilis](https://kompli.id/panduan/keamanan/pengembangan-aplikasi-yang-aman/)
- [Checklist persiapan pentest website dan aplikasi](https://kompli.id/template/checklist-persiapan-pentest/)