Threat Modeling Sederhana untuk Aplikasi Bisnis Kecil

Cara melakukan threat modeling dengan empat pertanyaan, diagram alur data, dan STRIDE untuk aplikasi bisnis kecil, cukup dengan kertas dan diskusi.

Ditulis olehLucas Tan

Terbit 11 November 2026 6 menit baca

Jawaban singkat

Threat modeling adalah memetakan apa yang bisa salah pada aplikasi sebelum penyerang menemukannya. Untuk bisnis kecil cukup empat pertanyaan, satu diagram alur data, daftar ancaman STRIDE, dan keputusan tertulis untuk tiap risiko.

Daftar isi

Pernahkah kamu meluncurkan aplikasi kasir, portal pelanggan, atau sistem order, lalu baru terpikir soal keamanan setelah ada yang aneh? Threat modeling adalah kebiasaan sederhana untuk membalik urutan itu: duduk sebentar sebelum (atau sesudah) membangun, lalu bertanya apa saja yang bisa salah dan apa yang akan kamu lakukan.

Kabar baiknya, threat modeling tidak harus memakai alat mahal atau konsultan. Untuk aplikasi bisnis kecil, satu sesi diskusi dengan pengembang dan pemilik proses, satu lembar diagram, dan satu tabel keputusan sudah memberi hasil yang berguna. Panduan ini memakai kerangka yang dipakai OWASP: empat pertanyaan inti dan kategori ancaman STRIDE.

Empat pertanyaan yang jadi kerangkanya

OWASP Threat Modeling Cheat Sheet dan Threat Modeling Manifesto merangkum prosesnya dalam empat pertanyaan:

Apa yang sedang kita kerjakan?
Apa yang bisa salah?
Apa yang akan kita lakukan tentang itu?
Apakah hasil kerja kita sudah cukup baik?

Langkah-langkah di bawah adalah cara menjawab keempatnya secara praktis.

Langkah demi langkah threat modeling sederhana

Langkah 1: Tentukan batas dan aset yang dilindungi

Pilih satu aplikasi atau satu fitur, jangan seluruh bisnis sekaligus. Misalnya "aplikasi order online beserta panel admin". Lalu tulis aset yang paling berharga: data pelanggan, data pembayaran, stok, akun admin, reputasi toko.

Daftar aset ini membantu menentukan prioritas nanti. Ancaman terhadap akun admin jelas lebih penting daripada ancaman terhadap halaman "tentang kami".

Langkah 2: Gambar diagram alur data

Di kertas atau papan tulis, gambar empat jenis elemen:

Entitas luar: pelanggan, admin, payment gateway, layanan pengiriman.
Proses: aplikasi web, API, skrip cron.
Penyimpanan data: database, folder upload, backup.
Alur data: panah yang menunjukkan data mengalir dari mana ke mana.

Lalu tandai batas kepercayaan (trust boundary), yaitu garis tempat data berpindah dari pihak yang kurang dipercaya ke pihak yang lebih dipercaya. Contohnya antara browser pelanggan dan server, antara server dan payment gateway, atau antara panel admin dan database. OWASP mencatat batas kepercayaan seperti ini sering menjadi titik serangan, jadi di situlah perhatianmu paling banyak.

Langkah 3: Cari ancaman dengan STRIDE

Untuk setiap elemen dan setiap panah yang melewati batas kepercayaan, ajukan enam pertanyaan STRIDE. Tabel ringkasnya:

Kategori	Artinya	Contoh pertanyaan di aplikasi order
Spoofing	Menyamar sebagai pengguna atau komponen lain	Bisakah orang login sebagai admin dengan password tebakan?
Tampering	Mengubah data tanpa izin	Bisakah harga di keranjang diubah dari browser?
Repudiation	Menyangkal perbuatan, misalnya karena log tidak ada	Kalau stok berubah, apakah tercatat siapa yang mengubah?
Information disclosure	Data terbuka ke pihak yang tidak berhak	Bisakah pelanggan A melihat invoice pelanggan B dengan mengganti ID di URL?
Denial of service	Layanan dibuat tidak bisa dipakai	Apa yang terjadi bila form order dikirim ribuan kali?
Elevation of privilege	Mendapat hak lebih dari seharusnya	Bisakah staf gudang membuka menu laporan keuangan?

Tulis semua jawaban "bisa" atau "tidak tahu" ke daftar ancaman. Jangan menyaring terlalu cepat. Ide yang terdengar mustahil sering ternyata mudah dilakukan.

Langkah 4: Putuskan respons untuk setiap ancaman

OWASP mengutip empat pilihan respons:

Mitigasi: kurangi kemungkinannya, misalnya memasang 2FA untuk admin atau memvalidasi harga di server.
Eliminasi: hapus fitur yang menimbulkan risiko, misalnya mematikan upload file yang tidak dipakai.
Transfer: alihkan tanggung jawab ke pihak lain, misalnya pembayaran kartu ditangani payment gateway. Risiko yang tersisa tetap harus dicatat.
Terima: biarkan risiko dengan sadar karena biaya penanganannya tidak sebanding, lalu tulis alasannya.

Untuk tiap ancaman, beri nilai sederhana: dampak (rendah/sedang/tinggi) dan kemungkinan (rendah/sedang/tinggi). Kerjakan dulu yang tinggi-tinggi.

Langkah 5: Catat, bagi tugas, dan tentukan tenggat

Hasil threat modeling yang tidak dicatat akan hilang dalam sebulan. Simpan tabel sederhana berisi ancaman, respons yang dipilih, penanggung jawab, dan tenggat. Spreadsheet bersama sudah cukup.

Langkah 6: Tinjau ulang saat aplikasi berubah

Pertanyaan keempat, "apakah sudah cukup baik", dijawab dengan meninjau ulang. Ulangi sesi singkat setiap ada fitur besar baru, integrasi dengan layanan luar, atau perubahan cara login. Periksa juga apakah mitigasi yang dijanjikan benar-benar sudah terpasang.

Contoh singkat: fitur upload bukti transfer

Bayangkan aplikasi order punya fitur pelanggan mengunggah foto bukti transfer. Beberapa ancaman yang muncul dari STRIDE:

Tampering dan elevation of privilege: file yang diunggah ternyata skrip yang bisa dijalankan server. Mitigasi: batasi tipe file, simpan di luar folder web, ganti nama file.
Information disclosure: URL bukti transfer bisa ditebak sehingga orang lain bisa melihat foto rekening pelanggan. Mitigasi: nama file acak dan cek kepemilikan sebelum menampilkan.
Repudiation: pelanggan mengaku sudah transfer, admin mengaku tidak menerima. Mitigasi: catat waktu unggah dan siapa admin yang memverifikasi.

Tiga ancaman ini ditemukan dalam beberapa menit diskusi, dan semuanya lebih murah dicegah sekarang daripada ditangani setelah kejadian.

Siapa yang perlu ikut dalam sesi?

Idealnya tiga sudut pandang: orang yang membangun aplikasi (tahu cara kerjanya), orang yang memakai atau mengelola prosesnya (tahu celah prosedur), dan seseorang yang bertugas mengajukan pertanyaan "bagaimana kalau". Peran terakhir bisa bergantian.

Kalau kamu memakai vendor untuk membuat aplikasi, minta mereka ikut. Vendor yang serius biasanya senang diajak, karena hasilnya juga melindungi mereka. Untuk pemeriksaan lanjutan setelah aplikasi jadi, pengujian penetrasi bisa membuktikan apakah ancaman di daftar benar-benar bisa dieksploitasi. Cara membaca hasilnya dibahas di isi laporan pentest dan cara membacanya.

Pertanyaan yang sering diajukan

Apa bedanya threat modeling dengan pentest?

Threat modeling dilakukan di atas kertas untuk memetakan apa yang bisa salah, idealnya sebelum atau saat membangun. Pentest menguji aplikasi yang sudah berjalan untuk membuktikan celah nyata. Keduanya saling melengkapi.

Apakah harus memakai STRIDE?

Tidak wajib. STRIDE populer karena mudah diingat dan mencakup banyak jenis ancaman. Yang penting ada cara sistematis supaya diskusi tidak hanya mengandalkan ingatan.

Berapa lama satu sesi threat modeling?

Untuk satu fitur atau aplikasi kecil, satu sesi singkat biasanya cukup untuk menghasilkan daftar ancaman awal. Lebih baik sesi pendek tapi rutin daripada satu sesi panjang yang tidak pernah diulang.

Apakah ada alat bantu gratis?

Ada, misalnya OWASP Threat Dragon dan Microsoft Threat Modeling Tool untuk menggambar diagram dan mencatat ancaman. Tapi kertas dan spreadsheet sudah cukup untuk memulai.

Ancaman apa yang paling sering muncul di aplikasi bisnis kecil?

Biasanya seputar login admin yang lemah, akses data antarpelanggan yang tidak dicek, dan kredensial yang tersimpan sembarangan. Daftar celah aplikasi web yang umum ada di OWASP Top 10.

Checklist sesi threat modeling pertamamu:

Satu aplikasi atau fitur yang jelas batasnya.
Daftar aset yang paling berharga.
Diagram alur data dengan batas kepercayaan.
Daftar ancaman per kategori STRIDE.
Keputusan respons, penanggung jawab, dan tenggat.
Jadwal tinjauan ulang. Untuk menyusun aturan keamanan yang lebih luas, lihat kebijakan keamanan IT sederhana untuk UMKM dan OWASP Top 10 untuk pemilik website.