Keamanan Aplikasi Mobile Jebol di Batas WebView/API: Apa yang Perlu Diuji dan Ditegakkan Minggu Ini

Rantai eksploitasi ini bukan soal teori minggu ini

Pada 21 Maret 2026, Axios melaporkan bahwa rangkaian eksploitasi iOS baru bernama “DarkSword” dapat memungkinkan spyware mencuri data sensitif—karena komponen iOS yang diproses dan diperkokoh dapat dilewati, bukan “dibereskan” dengan sekadar pemulihan. (Sumber: axios.com) (axios.com)

Ini menjadi persoalan keamanan mobile karena sebagian besar aplikasi nyata tidak “murni native”. Aplikasi modern bersifat hibrida: ada shell native, antarmuka WebView/WebKit, API di lapisan aplikasi, serta SDK pihak ketiga. Jika salah satu mata rantai lemah, penyerang tidak perlu menumbangkan OS untuk menjangkau data. Yang diperlukan hanya mematahkan asumsi antar-lapisan—dari konten web ke jembatan native, dari navigasi ke pengecekan origin, dari validasi TLS ke kepercayaan pada API, atau dari IPC/auth SDK ke kepercayaan pada backend.

Apple berupaya menurunkan probabilitasnya lewat pembaruan keamanan untuk komponen latar (background) dan Lockdown Mode sebagai opsi ekstrem menghadapi spyware mercenary yang canggih. “Background Security Improvements” Apple dijelaskan sebagai rilis keamanan ringan untuk komponen seperti Safari/WebKit dan pustaka sistem, dikirim di sela rilis besar OS, serta mulai diaktifkan sejak iOS 26.1. (Sumber: support.apple.com) (support.apple.com) Apple juga mendeskripsikan Lockdown Mode sebagai upaya mengurangi attack surface dengan membatasi tajam fungsionalitas yang berpotensi dieksploitasi oleh spyware mercenary. (Sumber: apple.com) (apple.com)

Namun, pengerasan platform tidak akan menyelamatkan aplikasi enterprise bila lapisan WebView atau API memungkinkan konten web berbahaya mencapai aksi istimewa aplikasi. Pengujian dan penegakan harus mengasumsikan penyerang memulai dari “konten web yang tidak tepercaya” lalu berakhir pada “panggilan API aplikasi berprivilege”—setelah itu, verifikasi setiap tautan.

Jadi, apa yang dilakukan: Perlakukan aplikasi mobile sebagai sistem batas (boundary system), bukan sebagai produk tunggal. Minggu ini, utamakan seam testing: perilaku navigasi dan bridge pada WebView, validasi sertifikat/TLS, serta jalur otorisasi API yang dapat dijangkau dari permukaan Web atau SDK.

Petakan batas menuju privilege aplikasi

WebView adalah mesin peramban yang tertanam di dalam aplikasi. WebKit adalah mesin peramban milik Apple; di Android, WebView berbasis Chromium. Risiko keamanan muncul ketika aplikasi memberi JavaScript atau navigasi web sebuah “pegangan” menuju kode native atau API aplikasi.

Di Android, MASTG dari OWASP menyediakan panduan konkret untuk memverifikasi kontrol terkait WebView, termasuk cara antarmuka JavaScript diperlakukan dan bagaimana navigasi atau pemuatan konten seharusnya berperilaku. Sebagai contoh, entri pengetahuan MASTG memperingatkan jebakan historis seputar addJavascriptInterface ketika JavaScript berbahaya dapat disuntikkan ke WebView. (Sumber: mas.owasp.org) (mas.owasp.org)

Di iOS, seam tetap ada sekalipun detail internal WebKit membaik. “Background Security Improvements” Apple secara eksplisit menyoroti tumpukan framework Safari browser dan WebKit sebagai komponen yang dapat menerima rilis keamanan di sela pembaruan OS besar. (Sumber: support.apple.com) (support.apple.com) Risiko tertentu memang berkurang, tetapi isu khas aplikasi tidak otomatis terselesaikan—misalnya ketiadaan origin checks di native bridge, atau pemanggilan API yang menerima token yang dikendalikan penyerang.

Hubungkan ini dengan OWASP Mobile Top 10. Rilis OWASP Mobile Top 10 2024 disusun berdasarkan kategori kategori kerentanan yang umum, dan dipelihara melalui metodologi berbasis data. (Sumber: owasp.org) (owasp.org) Kategori yang relevan untuk batas rantai eksploitasi biasanya mencakup:

• Pola komunikasi yang tidak aman (kelemahan validasi TLS yang membuat lalu lintas yang dipengaruhi penyerang dapat mencapai API).
• Otentikasi/otorisasi yang tidak aman (backend mempercayai input klien atau memvalidasi buruk token sesi).
• Konfigurasi keamanan yang keliru dan penyimpanan data yang tidak aman yang mengubah satu kompromi menjadi penyalahgunaan data yang bertahan.

Halaman kategori Mobile Top 10 OWASP juga memuat ekspektasi pengujian. Misalnya, kategori M3 “Insecure Authentication/Authorization” mencantumkan panduan tester seperti mencoba mengeksekusi fungsionalitas backend secara anonim dengan menghapus session tokens dari request untuk fungsi mobile. (Sumber: owasp.org) (owasp.org)

Jadi, apa yang dilakukan: Jangan hanya melakukan pemindaian “kerentanan WebView” secara terpisah. Bangun uji rantai eksploitasi yang dimulai dari konten web berbahaya dan membuktikan apakah konten itu dapat mencapai perilaku native berprivilege—lalu verifikasi bahwa backend tetap menegakkan otorisasi ketika sinyal sisi-klien dihapus atau dimanipulasi.

Kategori OWASP yang perlu diuji lebih dulu

OWASP juga memelihara Mobile Application Security Verification Standard (MASVS) dan Mobile Application Security Testing Guide (MASTG), yang menerjemahkan kategori kerentanan menjadi langkah verifikasi. OWASP menjelaskan MASTG sebagai panduan yang menguraikan proses teknis untuk memverifikasi kontrol aplikasi mobile. (Sumber: devguide.owasp.org) (devguide.owasp.org)

Mulailah dengan dua kategori Mobile Top 10 yang paling sering gagal tepat di batas:

Komunikasi yang tidak aman dan validasi TLS

Jika lapisan jaringan aplikasi menerima sertifikat yang tidak tepercaya, verifikasi host yang lemah, atau penyimpanan sertifikat kustom yang salah, penyerang dapat menyadap atau mengubah lalu lintas meskipun tumpukan peramban OS sudah diperkeras. Dokumentasi pengembang Android sendiri membahas validasi sertifikat dan merujuk Network Security Configuration serta pengaturan opt-in certificate transparency. (Sumber: developer.android.com) (developer.android.com)

MASTG memuat pengujian khusus untuk certificate pinning dan penyimpanan sertifikat kustom. Salah satu contohnya ialah “MASTG-TEST-0022: Testing Custom Certificate Stores and Certificate Pinning”, yang mencakup output troubleshooting dan secara tegas membingkainya sebagai masalah otentikasi identitas server. (Sumber: mas.owasp.org) (mas.owasp.org)

Otentikasi dan otorisasi yang tidak aman

Panduan OWASP M3 menekankan bahwa tester perlu menghapus session tokens dan mencoba memanggil fungsionalitas backend secara anonim. Ini persis jenis pemeriksaan pemutusan rantai yang dibutuhkan: sekalipun WebView berhasil memicu pemanggilan API di dalam aplikasi, backend tidak boleh memperlakukan “kehadiran token” sebagai bukti yang cukup tanpa verifikasi ketat. (Sumber: owasp.org) (owasp.org)

MASTG dan MASVS juga mendukungnya melalui control-group testing yang selaras dengan threat model. OWASP mencatat bahwa penggunaan MASTG/MASVS perlu digerakkan oleh threat modeling untuk menentukan profil pengujian yang tepat. (Sumber: mas.owasp.org) (mas.owasp.org)

Jadi, apa yang dilakukan: Bangun matriks uji boundary: untuk setiap aksi berprivilege yang dipicu WebView, jalankan dua jenis uji—(a) uji validasi sertifikat/TLS untuk memastikan identitas server ditegakkan, dan (b) uji manipulasi otorisasi, di mana session tokens dihapus atau diubah. Jika salah satu gagal, rantai eksploitasi dianggap operasional. Jadikan matriks ini terukur dengan menetapkan kriteria lulus untuk tiap sel: aplikasi harus memblokir aksi secara lokal (penegakan bridge/origin/route) atau backend harus mengembalikan penolakan tegas (misalnya 401/403) sambil mencatat alasan kegagalan otorisasi—bukan “fallback” senyap yang tetap menyelesaikan request berprivilege.

Validasi navigasi dan perilaku bridge

“MAST” sering diperlakukan sebagai lembar kerja spreadsheet kasus uji. Secara praktik, MAST seharusnya menjadi disiplin validasi boundary: membuktikan bahwa navigasi, origin, dan perilaku bridge tidak dapat disiasati hingga melakukan panggilan berprivilege.

Asumsi same-origin dalam komponen Web

Konsep keamanan di sini adalah same-origin policy. Dalam bahasa sederhana, konsep ini berarti skrip dari satu “origin” (kurang lebih: skema + host + port) tidak bisa membaca data secara bebas atau memanggil antarmuka berprivilege dari origin lain. Implementasi WebView bisa membuat asumsi ini rapuh saat aplikasi memuat file lokal, URL kustom file://, atau melakukan redirect melalui handler navigasi.

Di Android, dokumentasi WebView Chromium memperingatkan bahwa API seperti setAllowFileAccessFromFileURLs dapat mengubah cara URL file:// diperlakukan dalam kaitannya dengan perilaku origin. (Sumber: chromium.googlesource.com) (chromium.googlesource.com) Dokumentasi Android WebSettings API juga menjelaskan setAllowFileAccess dan menyarankan penggunaan asset loader alih-alih skema file:// untuk mengakses file. (Sumber: developer.android.com) (developer.android.com)

MASTG memuat pengetahuan WebView yang menghubungkan pengaturan-pengaturan ini dengan outcome keamanan, termasuk peringatan tentang JavaScript yang tidak tepercaya berinteraksi dengan antarmuka yang disuntikkan. (Sumber: mas.owasp.org) (mas.owasp.org)

Permukaan bridge dan SDK IPC/auth

Seam ini kerap bukan sekadar “WebView”. Seam terletak pada bridge: WebView Anda memanggil kode native (atau kode native memanggil SDK). Penyerang membidik confused deputy—ketika permintaan yang dikendalikan penyerang membuat aplikasi atau SDK bertindak dengan hak istimewa lebih tinggi daripada yang semestinya.

Data implementasi langsung untuk mekanisme IPC/auth setiap vendor tidak akan dipublikasikan. Namun, kelas risiko yang mendasarinya didukung kuat dalam riset keamanan mobile dan praktik pengujian yang selaras OWASP: pastikan aksi yang dimediasi SDK dan komunikasi inter-process mensyaratkan verifikasi server yang kuat, serta tidak dapat diulang atau dipanggil tanpa pemeriksaan identitas dan otorisasi pemanggil yang memadai. Salah satu contoh riset menilai mekanisme autentikasi Android IPC terhadap threat model berbasis SDK dan mengusulkan arsitektur pertahanan yang menggabungkan verifikasi pemanggil serta validasi certificate-hash di sisi server. (Sumber: arxiv.org) (arxiv.org)

Bagian yang sering kurang diuji bukan apakah “IPC ada”, melainkan apakah aplikasi dan backend memperlakukan konteks bridge sebagai input yang tidak tepercaya. Untuk setiap metode bridge berprivilege (pembayaran, tautan akun, pengambilan pesan, pembaruan profil), verifikasi dua hal saat navigasi berada dalam kondisi bermusuhan:

1. Keterikatan pemanggil: jika bridge menerima parameter (ID, nominal, identitas perangkat, target redirect), aplikasi harus mengikat parameter tersebut ke status pengguna/sesi yang tervalidasi server—bukan ke klaim apa pun yang dibuat halaman web.
2. Ketahanan replay / kesegaran: jika aplikasi menerbitkan request yang kemudian ditebus oleh backend (atau oleh sebuah SDK), pastikan penebusan memerlukan konteks segar yang dikeluarkan server, bukan token jangka panjang atau nonce yang disuplai klien.

Jadi, apa yang dilakukan: Untuk setiap jalur WebView yang memicu aksi native (pembayaran, tautan akun, pengambilan pesan, pembaruan profil), buat skenario MAST yang memvariasikan input navigasi (redirect, mixed content, URL file lokal bila digunakan). Setelah itu, pastikan aksi tetap gagal ketika asumsi origin tidak terpenuhi dan ketika token/klaim dimanipulasi. Perluas skenario dengan “hostility” pada parameter bridge: ubah setiap pengenal/nominal/target redirect yang disuplai klien sambil mempertahankan sesi yang sama dan terautentikasi—lalu konfirmasi backend menolak inkonsistensi (atau aplikasi menolak menerbitkan request berprivilege).

Patch dan penegakan di OS dan Web

Manajemen keamanan mobile enterprise paling sering gagal ketika tim melakukan patch, tetapi mengabaikan drift komponen. Aplikasi mobile tidak bergantung semata pada kode. Aplikasi bergantung pada komponen OS, tumpukan WebKit/WebView, dan pustaka pihak ketiga.

Perbaikan patch keamanan background di Apple

Apple’s Background Security Improvements secara eksplisit digambarkan sebagai “lightweight security releases” untuk komponen seperti Safari dan WebKit serta pustaka sistem lainnya, yang diaktifkan mulai iOS 26.1. (Sumber: support.apple.com) (support.apple.com) Artinya, postur risiko perangkat bisa membaik di sela rilis besar aplikasi, tetapi hanya jika perangkat memenuhi syarat dan benar-benar menerima pembaruan background tersebut.

Ini semestinya mengubah operasi enterprise. Diperlukan telemetri apakah background security improvements diaktifkan dan diterapkan, bukan hanya angka versi aplikasi. (Sumber: support.apple.com) (support.apple.com)

Agar menjadi operasional, bukan sekadar harapan, perlakukan pembaruan background Apple sebagai sinyal kepatuhan yang bisa dipantau dalam dua lapis:

• Lapis eligibility: catat versi iOS perangkat (≥ 26.1) dan apakah kebijakan pengguna/organisasi membuat perangkat tetap eligible untuk menerima rilis keamanan komponen.
• Lapis applied: pasang instrumen bergaya attestation (dari aplikasi) yang melaporkan status komponen/keamanan perangkat yang benar-benar bisa diamati organisasi (meski bersifat kasar). Jika sinyal tidak dapat diamati secara andal, kontrol kepatuhan harus mengalami degradasi yang “graceful”: mewajibkan dorongan “update recommended” yang terlihat pengguna dan memperketat penilaian risiko di sisi server sampai konfirmasi diterima.

Manajemen pembaruan sistem untuk enterprise di Android

Di Android, kontrol enterprise tersedia untuk mengelola pembaruan sistem. “Manage system updates” dari Android Developers menjelaskan penggunaan device policy controller untuk memeriksa ketersediaan update sistem serta menerapkan aturan penundaan, sekaligus menyebutkan bahwa pabrikan perangkat atau operator dapat mengecualikan pembaruan keamanan penting dari penundaan. (Sumber: developer.android.com) (developer.android.com)

Inilah tuas kebijakan yang dibutuhkan enterprise untuk penegakan enforcement patch keamanan. Tidak cukup hanya menyuruh pengguna “memperbarui”. Organisasi harus menetapkan dan memverifikasi status kebijakan serta memastikan status patch keamanan bergerak sesuai ekspektasi.

Pembaruan WebView yang dikelola bisa mengganggu perangkat

Bahkan jika penegakan patch tersedia, implementasi terkelola di dunia nyata dapat menemui gesekan operasional. Dokumentasi Samsung Knox membahas isu bahwa pembaruan Android System WebView pada perangkat terkelola dapat menyebabkan reboot tak terduga, serta menyarankan langkah perbaikan seperti menonaktifkan pembaruan aplikasi melalui profil EMM. (Sumber: docs.samsungknox.com) (docs.samsungknox.com)

Inilah alasan mengapa manajemen keamanan aplikasi mobile membutuhkan rencana gabungan patch-and-policy. Rilis aplikasi, patch OS, dan pembaruan komponen Web harus dikoordinasikan dengan pengaman operasional.

Jadi, apa yang dilakukan: Terapkan enforcement loop yang memperlakukan “versi aplikasi + status patch keamanan OS + status pembaruan komponen Web” sebagai satu objek kepatuhan. Tetapkan penanggung jawab dan ambang kegagalan (misalnya: blok akses ke API ketika status patch menurun, atau ketika komponen Web berada di bawah baseline yang disetujui). Secara konkret, tetapkan:

• baseline inventory (tingkat patch OS minimum dan versi/arc rilis minimum komponen WebView/WebKit yang dapat diterima),
• update SLO (misalnya “95% perangkat terkelola harus mencapai baseline dalam N hari sejak rilis”), dan
• respons playbook ketika pembaruan komponen Web berhenti (misalnya: kurangi bendera kemampuan aplikasi secara temporer, minta step-up auth untuk aksi berprivilege yang dipicu Web, atau naikkan penilaian risiko di sisi backend sampai pembaruan komponen Web terkonfirmasi).

Contoh kasus di boundary yang layak diulang

Di bawah ini terdapat kasus-kasus terdokumentasi yang memiliki nama, menunjukkan mengapa testing dan enforcement berbasis boundary itu penting. Ini merupakan skrip latihan: menggambarkan outcome dan timeline yang semestinya mengarahkan prioritas pengujian.

Rantai kompromi DarkSword dari web ke data

Axios melaporkan bahwa rantai eksploitasi “DarkSword” digunakan untuk mengambil data pribadi dari iPhone. Pemberitaan itu juga menautkan framing “spyware adalah masalah semua orang sekarang” ke mekanisme rantai eksploitasi, bukan ke perilaku pengguna. (Sumber: axios.com) (axios.com)
Timeline: Jendela 19–21 Maret 2026, berdasarkan berbagai laporan yang beredar dalam hitungan hari. (Sumber: axios.com) (axios.com)
Outcome: Menunjukkan bahwa kompromi iOS yang canggih dapat mencapai data sensitif, sehingga verifikasi boundary menjadi mendesak. (Sumber: axios.com) (axios.com)

Lockdown Mode menghambat perilaku spyware mercenary

Apple mendeskripsikan Lockdown Mode sebagai pembatasan fungsionalitas yang tajam untuk mengurangi attack surface terhadap spyware mercenary, serta memposisikannya sebagai perlindungan bagi pengguna yang mungkin menjadi target serangan siber yang sangat tersasar. (Sumber: apple.com) (apple.com)
Timeline: Diumumkan Juli 2022. (Sumber: apple.com) (apple.com)
Outcome: Mendukung sikap enterprise bahwa “mode ekstrem” dan konfigurasi yang diperkeras dapat mengganggu jalur-jalur spyware yang canggih. (Sumber: apple.com) (apple.com)
(Pemberitaan terpisah menyebutkan Lockdown Mode mengganggu skenario serangan grup NSO, tetapi pemetaan serangan yang presisi tidak sama dengan validasi boundary spesifik aplikasi.) (techcrunch.com)

WebView sandbox diperkeras di Android O

Blog Android Developers tentang keamanan WebView menjelaskan salah satu pertahanan platform utama: dimulai dengan Android O, renderer WebView berjalan dalam proses terisolasi yang terpisah dari aplikasi host, dengan pembatasan sandbox. (Sumber: android-developers.googleblog.com) (android-developers.googleblog.com)
Timeline: Pengumuman Juni 2017. (Sumber: android-developers.googleblog.com) (android-developers.googleblog.com)
Outcome: Menunjukkan kemajuan dalam mengisolasi kode renderer, tetapi juga tersirat bahwa aplikasi tetap harus menegakkan batasnya sendiri (perilaku bridge, penanganan token, dan autentikasi API). (android-developers.googleblog.com)

Pembaruan WebView yang dikelola bisa memicu reboot

Dokumentasi Samsung Knox mencatat bahwa pembaruan aplikasi Android System WebView pada perangkat terkelola dapat menyebabkan reboot tak terduga, dan menyarankan menonaktifkan pembaruan aplikasi lewat profil EMM sebagai jalur pemulihan. (Sumber: docs.samsungknox.com) (docs.samsungknox.com)
Timeline: Entri knowledge base yang terdokumentasi (tidak ada tanggal tunggal yang ditunjukkan pada cuplikan, tetapi berlaku untuk proses deployment terkelola yang nyata). (Sumber: docs.samsungknox.com) (docs.samsungknox.com)
Outcome: Menegaskan bahwa “enforcement patch” harus direkayasa secara operasional, bukan diasumsikan terjadi begitu saja.

Jadi, apa yang dilakukan: Susun playbook pengujian yang meniru outcome tersebut: (1) anggap rantai iOS yang canggih bisa mencapai data, (2) gunakan hardening platform bila tersedia, (3) tetap memperlakukan WebView sebagai boundary yang harus divalidasi, dan (4) desain rollout patch agar keamanan komponen Web tidak tertunda oleh insiden operasional.

Workflow enforcement untuk jendela rilis berikutnya

Workflow ini bisa dijalankan tanpa menunggu “rewrite total program keamanan mobile”.

1. Jalankan uji MASTG yang berfokus boundary untuk tiap rute WebView.
   Gunakan MASTG untuk kontrol WebView dan pengujian certificate pinning/custom store; masukkan skenario di mana konten web memicu aksi native lalu uji panggilan backend dengan session tokens yang dihapus/dimanipulasi, selaras dengan panduan tester OWASP M3. (Sumber: mas.owasp.org dan owasp.org dan mas.owasp.org) (mas.owasp.org)

2. Kunci validasi TLS dalam aplikasi.
   Verifikasi perilaku validasi TLS/certificate dan logika pinning menggunakan pengujian sertifikat MASTG yang khusus, alih-alih hanya mengandalkan “sudah pakai HTTPS”. (Sumber: developer.android.com dan mas.owasp.org) (developer.android.com)

3. Tegakkan kepatuhan perangkat lintas aplikasi, OS, dan tumpukan Web.
   Di iOS, perlakukan background security improvements sebagai kanal keamanan berbasis komponen, bukan sekadar catatan patch yang samar. (Sumber: support.apple.com) (support.apple.com) Di Android, tegakkan kebijakan update sistem lewat tooling Android Enterprise dan ukur progres status patch keamanan. (Sumber: developer.android.com) (developer.android.com)

4. Pre-test perilaku pembaruan komponen Web yang dikelola.
   Jika armada memakai perangkat Android terkelola, lakukan pre-test dampak pembaruan Android System WebView di bawah kendali manajemen agar drift keamanan tidak “diselesaikan” hanya dengan mematikan pembaruan. (Sumber: docs.samsungknox.com) (docs.samsungknox.com)

KPI tidak seharusnya berbunyi “kami merilis versi aplikasi baru”. KPI yang tepat adalah “setiap aksi berprivilege yang bisa dijangkau dari konten Web masih lolos otorisasi sisi server ketika token dihapus, dan setiap perangkat terkelola memenuhi baseline patch yang disepakati termasuk komponen Web”—begitulah realitas rantai eksploitasi berubah menjadi keputusan engineering.

Kesimpulan: tegakkan seam, lalu lindungi seam itu

Pembaharuan komponen background Apple dan Lockdown Mode menunjukkan arah perjalanan: mengurangi attack surface dan mengirim peningkatan keamanan bahkan di sela versi OS besar. (Sumber: support.apple.com dan apple.com) (support.apple.com) Tetapi highlight pemberitaan DarkSword menegaskan bahwa enterprise tidak bisa mengalihkan risiko sepenuhnya kepada pertahanan platform.

Wajibkan setiap fitur aplikasi yang bisa diakses dari konten WebView memiliki tiket pengujian boundary MASTG yang terikat pada kategori OWASP Mobile Top 10, dan wajibkan pemeriksaan kepatuhan perangkat mencakup status patch keamanan OS serta status pembaruan komponen sebelum izin mengakses API sensitif. Rekomendasi ini bersifat operasional karena OWASP dan MASTG secara eksplisit menghubungkan threat modeling ke profil pengujian serta proses verifikasi. (Sumber: mas.owasp.org dan devguide.owasp.org) (mas.owasp.org)

Dalam 3 hingga 6 bulan ke depan, lebih banyak enterprise diperkirakan akan memperlakukan “web component drift” sebagai isu kepatuhan, bukan semata isu pemeliharaan. Alasannya platform security improvements kini dikirim dalam rilis komponen yang lebih kecil (Apple), sementara Android Enterprise menyediakan kontrol pembaruan untuk kebijakan sistem (Android Enterprise system update policies). (Sumber: support.apple.com dan developer.android.com) (support.apple.com) Gunakan jendela rilis berikutnya untuk menjalankan boundary MASTG untuk aksi berprivilege yang dipicu WebView, sekaligus menginstrumentasi kepatuhan armada agar versi berisiko bisa diputus dengan cepat.

Jika membutuhkan satu aturan untuk sprint berikut: Uji seam tempat konten web memperoleh kekuatan native, lalu tegakkan baseline patch agar seam itu tidak bergeser diam-diam keluar dari batas keselamatan.