Perintah dan cakupan
Tinjau sebuah arsitektur di mana browser mengakses aplikasi web multi-tenant. Bagaimana Anda akan memetakan batas-batas dan aliran data, mengidentifikasi aset dan sumber ancaman, membedakan ancaman target, implementasi, dan eksternal, serta mengubah respons menjadi invarian keamanan yang dapat diverifikasi?
W3C Security Interest Group menerbitkan Threat Model for the Web Group Note Draft pada 26 Mei 2026. Dokumen ini bersifat informatif dan non-normatif, yang dimaksudkan untuk mendukung tinjauan keamanan pada spesifikasi Web baru. Sudut pandang sederhananya mencakup browser, DNS, Web Server, pengguna, dan operator jaringan. Wawancara ini menguji metode dan rantai bukti, bukan hafalan draf tersebut.
Apa yang dievaluasi oleh pewawancara
Pewawancara ingin melihat gambaran sistem dan aliran data sebelum daftar kerentanan; aset, pemangku kepentingan, dan sumber ancaman yang eksplisit; pembedaan yang jelas antara ancaman, kerentanan, dampak, dan respons; serta sasaran keamanan yang dinyatakan sebagai invarian yang dapat diperiksa. Jelaskan bagaimana model ini berkembang dan menjadi masukan bagi dokumen desain serta tinjauan. Jawaban yang kuat menyatakan batas-batas abstraksi, asumsi penyerang yang tidak dimodelkan, dan bagaimana dependensi di luar cakupan diserahterimakan.
Pertanyaan klarifikasi sebelum menjawab
- Apakah kita sedang meninjau platform browser, satu aplikasi web, atau Web API baru di antara keduanya?
- Apakah kredensial, data pengguna, kode, sesi, metadata jaringan, dan ketersediaan semuanya termasuk dalam cakupan?
- Apakah aliran data mencakup skrip pihak ketiga, CDN, DNS, penyedia identitas, dan permintaan lintas situs (cross-site)?
- Apakah ini tinjauan arsitektur, tinjauan keamanan pra-rilis, atau tinjauan perubahan operasional?
- Dependensi dan ancaman eksternal mana yang secara eksplisit berada di luar cakupan, dan siapa yang bertanggung jawab atas tindak lanjutnya?
Kerangka jawaban 30 detik
“Saya mulai dengan diagram aliran data yang memiliki ID unik untuk komponen, penyimpanan data, aliran data, dan pemangku kepentingan. Saya menginventarisasi aset dan sumber ancaman, lalu mencatat prasyarat, aliran yang terpengaruh, dampak, kontrol yang ada, dan risiko residual untuk setiap ancaman. Saya mengklasifikasikannya sebagai ancaman target, ancaman implementasi, atau dependensi eksternal. Setiap respons diubah menjadi invarian keamanan dengan bukti pengujian atau audit, pemilik tanggung jawab, dan pemicu pembaruan. Model ini dimulai dari use case dan berkembang seiring dengan desain sehingga versinya siap sebelum tinjauan keamanan formal.”
Pembahasan mendalam langkah demi langkah
1. Gambar batas sistem terlebih dahulu
Mulailah dengan skenario minimal yang dapat digunakan: proses dan penyimpanan browser, layanan DNS, Web Server, pengguna, administrator situs, dan operator jaringan. Berikan ID unik pendek untuk setiap komponen serta kamus deskriptif yang menjelaskan tanggung jawab dan batas kepercayaannya (trust boundary). Jika meninjau API baru, tempatkan input, output, izin, dan dependensinya ke dalam gambaran ini, alih-alih membuat diagram yang terisolasi.
2. Inventarisasi aset dan pemangku kepentingan
Aset dapat mencakup kredensial, token sesi, konten pengguna, skrip, identitas asal (source identity), hasil DNS, ketersediaan, dan metadata privasi. Pemangku kepentingan mencakup pengguna akhir, operator situs, operator jaringan, penyedia aplikasi, dan otoritas publik. Pisahkan pihak yang terpengaruh dari pihak yang berpotensi menyerang; memperlakukan pengguna hanya sebagai aset akan mengaburkan keputusan keselamatan yang penting.
3. Catat sumber ancaman dan ancaman tingkat tinggi
Untuk setiap ancaman, sebutkan sumbernya, aset sasaran, jalur serangan, dan dampaknya. Spoofing, tampering, pengungkapan informasi, denial of service, dan bypass otorisasi dapat digunakan untuk menyusun daftar, tetapi setiap entri harus dipetakan kembali ke aliran data konkret. Klasifikasikan ancaman sebagai ancaman target yang ditangani oleh spesifikasi, ancaman implementasi yang diketahui oleh pengembang tetapi tidak cocok untuk batasan normatif, atau ancaman eksternal dari dependensi dan deployment.
4. Ubah respons menjadi invarian
Invarian keamanan adalah kondisi yang harus selalu berlaku untuk setiap eksekusi yang diizinkan, seperti "respons cross-origin tidak pernah memberikan kredensial kepada pemanggil yang tidak sah" atau "pengalihan (redirect) tidak boleh melewati batas script-origin dan batas izin." Hubungkan setiap invarian dengan kontrol dan bukti pengujian, log, atau audit. Tandai apakah itu merupakan jaminan spesifikasi, jaminan implementasi, atau asumsi deployment.
component/flow -> asset -> threat source -> impact
-> invariant -> control -> evidence -> owner5. Tangani dependensi dan ancaman eksternal
Web bergantung pada DNS, TLS, HTTP, sertifikat, perutean, skrip, dan lapisan lainnya. Jangan berpura-pura bahwa satu model dapat mencakup setiap dependensi. Buat daftar asumsi yang diwarisi dan titik serah terima. Spoofing DNS, manipulasi sumber daya, atau pengawasan jaringan mungkin berada di luar spesifikasi saat ini, tetapi kutip model ancaman teknologi terkait dan catat asumsi yang Anda andalkan.
6. Jaga agar model tetap selaras dengan siklus hidup
Mulai threat model bersamaan dengan use case, explainer, dan draf desain awal, lalu perbarui seiring perubahan fitur dan aliran data. Pemicunya meliputi titik masuk baru, perubahan izin, dependensi baru, perubahan batas proses browser, dan insiden nyata. Berikan versi pada model, catatan tinjauan, dan diff agar tim dapat mengetahui apakah suatu risiko baru ditambahkan, ditutup, atau direklasifikasi. Versi yang lengkap harus sudah ada sebelum tinjauan keamanan horizontal formal dilakukan.
7. Buktikan bahwa respons berfungsi
Gunakan pengujian unit dan integrasi, pengujian keamanan browser, simulasi serangan, pemeriksaan konfigurasi, dan kueri log. Untuk invarian yang tidak dapat diuji secara langsung, berikan alasan yang dapat diaudit, risiko residual, dan pemilik yang menerima risiko tersebut. “Tidak ada kerentanan yang ditemukan” bukanlah bukti; nyatakan cakupan observasi, kondisi pengujian, dan area yang belum tercakup.
Contoh jawaban berkualitas tinggi
Saya akan mendefinisikan skenario akses browser minimal dengan ID unik untuk proses dan penyimpanan browser, DNS, Web Server, pengguna, dan operator jaringan, serta menyediakan kamus untuk setiap aliran data. Saya akan mencatat kredensial, sesi, konten pengguna, skrip, hasil resolusi, dan metadata privasi sebagai aset. Setiap ancaman akan mencakup sumber, prasyarat, aliran yang terpengaruh, dan dampak, kemudian diklasifikasikan sebagai ancaman target, implementasi, atau dependensi eksternal. Setiap respons akan menjadi invarian yang dapat diperiksa dan terikat pada kontrol, pengujian, log, atau bukti audit beserta pemiliknya. Model ini akan dimulai dari use case dan draf desain pertama, diperbarui saat titik masuk, dependensi, atau izin berubah, serta diberi versi sebelum tinjauan keamanan. Untuk DNS, TLS, skrip, dan perutean, saya akan mengutip model terkait dan menjelaskan risiko residual secara eksplisit. Hal ini membuat tinjauan bermanfaat baik untuk implementasi maupun perubahan di masa mendatang.
Kesalahan umum
- Hanya mendaftar nama kerentanan → tidak ada batasan atau aliran data → gambarkan komponen, aliran data, dan batas kepercayaan terlebih dahulu.
- Mencampuradukkan ancaman, kerentanan, dan dampak → respons tidak dapat diverifikasi → catat sumber, prasyarat, dampak, dan kontrol secara terpisah.
- Memasukkan semua risiko ke dalam spesifikasi saat ini → cakupan menjadi tidak realistis → klasifikasikan ancaman target, implementasi, dan eksternal.
- Hanya membuat satu model tepat sebelum rilis → perubahan desain terlewatkan → mulai dengan use case dan tentukan pemicu pembaruan.
- Menulis sasaran keamanan sebagai slogan → tidak ada bukti penerimaan → tulis ulang sebagai invarian yang terikat pada pengujian, log, atau audit.
- Mengabaikan risiko residual → keputusan tidak dapat dilacak → sebutkan area yang tidak tercakup, pemilik yang menerima risiko, dan tindakan tindak lanjut.
Pertanyaan lanjutan dan respons
Mengapa tidak menginventarisasi setiap penyerang terlebih dahulu?
Mendefinisikan komponen, aset, dan aliran data terlebih dahulu dapat mencegah pergeseran cakupan. Model penyerang dapat ditambahkan kemudian, tetapi spekulasi mengenai motif tidak dapat menggantikan analisis batasan dan kontrol yang dapat diverifikasi.
Bagaimana Anda menangani skrip pihak ketiga?
Masukkan sumber skrip, aliran pemuatan, kredensial yang dapat diakses, dan izin eksekusi ke dalam model. Tentukan pembatasan sumber, isolasi, dan invarian pemantauan; jika vendor mengelola suatu kontrol, catat bukti serah terima dan risiko residualnya.
Kapan dependensi eksternal menjadi risiko proyek?
Ketika asumsi keamanannya secara langsung memengaruhi aset atau invarian dalam cakupan, atau proyek tidak dapat memverifikasi jaminan dependensi tersebut, catat hal itu sebagai risiko saat ini dengan mitigasi atau pemilik yang menerima risiko, bukan sekadar catatan kaki.
Bagaimana jika model tinjauan keamanan terlalu kompleks?
Pertahankan diagram minimal yang mencakup risiko-risiko utama, bagi detail protokol atau deployment ke dalam sub-model yang saling terhubung, dan pertahankan keterlacakan dengan ID komponen dan aliran. Jangan mengurangi kompleksitas dengan menghapus batas yang kritis.
Bagaimana Anda menjelaskan risiko residual kepada product owner?
Jelaskan aset yang terpengaruh, jalur serangan yang masuk akal, kontrol saat ini, bukti pengujian, dan dampak bisnisnya. Tawarkan opsi dengan estimasi biaya, tenggat waktu, dan pemilik penerima risiko yang eksplisit; hindari klaim "benar-benar aman" atau klaim probabilitas yang tidak didukung data.