Wawancara Frontend: Bagaimana Anda merancang izin ekstensi browser dengan prinsip hak istimewa terendah (least-privilege)?

Perintah dan konteks yang sesuai

Ekstensi ini memproses halaman saat ini hanya setelah klik toolbar yang eksplisit, lalu mengirimkan bidang yang telah difilter ke backend terkontrol. Ekstensi tidak memerlukan pemindaian latar belakang pada setiap tab atau akses ke cookie situs arbitrer. Usulkan pemisahan izin Manifest V3, alur runtime, penurunan bertahap (graceful degradation), dan rencana verifikasi rilis.

Pertanyaan ini menguji batasan izin ekstensi browser dan keamanan produk. Backend tetap bertanggung jawab atas autentikasi, minimalisasi data, dan kontrol audit; izin ekstensi tidak menggantikannya.

Apa yang dievaluasi pewawancara

Pewawancara ingin melihat kemampuan API, host yang dapat dijangkau, dan persetujuan pengguna diperlakukan sebagai keputusan terpisah. Chrome mendokumentasikan izin API, izin host, izin opsional, dan activeTab secara terpisah; semuanya memengaruhi API yang tersedia, akses URL, peringatan instalasi, dan perilaku pembaruan.

Jawaban yang kuat dimulai dengan kapabilitas terkecil, menjelaskan mengapa tindakan satu kali pada halaman saat ini tidak boleh meminta <all_urls>, dan mencakup penolakan, pencabutan izin, upgrade, dan telemetri. Sekadar mengatakan "tambahkan izin" tidak menunjukkan siklus hidup yang aman.

Klarifikasi yang perlu ditanyakan terlebih dahulu

• Apakah "halaman saat ini" mencakup halaman khusus, frame lintas-asal (cross-origin), URL file, atau jendela penyamaran (incognito)?
• Apakah API memerlukan dokumen lengkap atau hanya bidang yang dipilih pengguna?
• Haruskah ekstensi mengamati perubahan halaman saat pengguna belum mengkliknya?
• Implementasi WebExtensions mana saja yang harus didukung?
• Bisakah kebijakan perusahaan (enterprise policy) mengonfigurasi izin sebelumnya, dan berapa lama bidang audit boleh disimpan?

Kerangka jawaban 30 detik

"Saya akan membagi kemampuan menjadi pembacaan halaman saat ini, komunikasi backend, dan penyimpanan. Untuk tindakan satu kali, saya akan menggunakan activeTab alih-alih akses host yang luas. Hanya fitur latar belakang lintas halaman yang sebenarnya yang membenarkan optional_host_permissions yang presisi, yang diminta saat pengguna memicu fitur tersebut. Saya hanya akan mendeklarasikan izin API yang diperlukan, berhenti saat ada penolakan atau pencabutan, dan menyediakan fallback salin manual. Sebelum upgrade, saya akan membandingkan perbedaan izin dan memantau akses serta aliran data baru; rollback akan menghapus kemampuan baru tersebut."

Jawaban mendalam langkah demi langkah

Langkah 1: Memetakan perilaku ke izin

Izin API seperti storage dan scripting menyediakan kapabilitas API ekstensi; izin host menentukan rentang URL yang dapat diajak berinteraksi. Manifest harus diturunkan dari setiap aliran data, bukan dari fitur yang mungkin diperlukan nanti.

Titik awal untuk memproses hanya tab tempat pengguna mengklik adalah:

{
  "manifest_version": 3,
  "permissions": ["activeTab", "scripting", "storage"],
  "optional_host_permissions": ["https://app.example.com/*"]
}

Saat skrip diinjeksikan hanya ke halaman saat ini, activeTab memberikan akses sementara setelah tindakan pengguna; menutup atau menavigasi tab akan mengakhirinya. Jika produk benar-benar membutuhkan pemrosesan latar belakang untuk app.example.com, evaluasi izin host opsional yang presisi alih-alih menggunakan default *://*/*.

Langkah 2: Merancang persetujuan progresif

Minta hanya kemampuan inti berisiko lebih rendah pada saat instalasi. Saat pengguna mengklik "Analisis halaman ini," periksa URL terhadap kumpulan yang diizinkan. Jika diperlukan host tambahan, panggil chrome.permissions.request() dan jelaskan tujuan, cakupan, dan cara keluar dari fitur tersebut.

const granted = await chrome.permissions.request({
  origins: ["https://app.example.com/*"]
});
if (!granted) {
  showManualCopyFallback();
  return;
}

Keberhasilan berarti kapabilitas browser tersedia; ini tidak melewati autentikasi backend. Jika permintaan gagal, pengguna kemudian mencabutnya, atau kebijakan menonaktifkannya, kembali ke status tanpa izin tanpa menampilkan prompt berulang kali.

Langkah 3: Membedakan status aktif, diberikan, dan dapat dicabut

Chromium membedakan izin yang sedang aktif dari izin yang diberikan secara historis. chrome.permissions.remove() mengurangi kapabilitas saat ini, sementara kumpulan izin historis mungkin masih mencatat izin tersebut; permintaan berikutnya mungkin tidak menampilkan prompt yang sama lagi. Keputusan runtime harus menggunakan apa yang tersedia saat ini, dan pengaturan harus menyediakan tindakan pencabutan yang jelas.

Sebelum setiap tugas, panggil chrome.permissions.contains() untuk izin yang sebenarnya. Selama tugas berlangsung, dengarkan permissions.onRemoved; hentikan pembacaan dan pengunggahan, bersihkan antrean keluar, dan catat peristiwa perubahan izin yang dapat diaudit.

Langkah 4: Menangani penolakan, upgrade, dan rollback

Saat terjadi penolakan, sajikan langkah berikutnya yang non-teknis seperti pemilihan manual, salin dan tempel, atau keluar. Jangan mengklasifikasikan penolakan sebagai kesalahan jaringan atau mencoba lagi permintaan izin di latar belakang.

Sebelum rilis, buat diff izin yang mencakup API baru, pola host, pencocokan content-script, dan bidang data. Chrome dapat menonaktifkan ekstensi ketika pembaruan meningkatkan hak istimewa dan menunggu persetujuan baru. Menghapus izin juga tidak serta merta menghapus riwayat izin yang diberikan sebelumnya, sehingga uji rollback harus mencakup pengguna yang sebelumnya memberikannya dan pengguna yang tidak pernah memberikannya.

Langkah 5: Menjadikan izin sebagai batas keamanan yang dapat diuji

Content script memproses input yang dikontrol halaman, sehingga penangan pesan harus memvalidasi pengirim, jenis pesan, dan ukuran. Backend harus mengotorisasi ulang identitas ekstensi, identitas pengguna, sumber daya target, dan daftar izin bidang (allowlist). Izin host membatasi kemampuan browser; izin tersebut tidak membuat halaman menjadi tepercaya atau menghentikan ekstensi dari mengirim data yang dibaca ke backend yang salah.

Sebelum peluncuran, buat matriks untuk instalasi, izinkan, tolak, cabut, kedaluwarsa activeTab setelah navigasi, permintaan host opsional, pembaruan peningkat izin, rollback, penonaktifan kebijakan perusahaan, browser yang tidak didukung, dan mode offline. Telemetri harus mencatat kunci izin, pola host, hasil, dan versi, jangan pernah mencatat teks halaman.

Contoh jawaban berkualitas tinggi

"Saya akan mulai dengan peta kapabilitas dan aliran data. Karena tindakan toolbar hanya memproses halaman saat ini, desain inti menggunakan activeTab, scripting, dan storage yang diperlukan, tanpa akses ke semua situs. Hanya fitur latar belakang untuk app.example.com yang akan menggunakan izin host opsional yang presisi, yang diminta saat pengguna memicunya. Saya akan menjelaskan tujuan dan cakupan sebelum permintaan, menawarkan pemilihan manual setelah penolakan, dan menghindari perulangan prompt.

Sebelum setiap tugas, saya akan memeriksa izin saat ini dan mendengarkan pencabutan izin. Jika akses hilang, hentikan pembacaan, bersihkan antrean keluar, dan minta backend mengotorisasi ulang identitas dan sumber daya. Sebelum pembaruan, buat diff perubahan API, host, dan content-script, lalu uji penonaktifan, persetujuan baru, dan rollback. Terakhir, gunakan matriks izin dan telemetri yang dianonimkan untuk memverifikasi tidak ada pemindaian latar belakang, tidak ada injeksi lintas host, tidak ada teks halaman dalam log, dan penurunan bertahap yang aman saat terjadi penolakan dan pencabutan izin."

Kesalahan umum

• Meminta <all_urls> secara default → memperluas paparan pembacaan dan injeksi serta meningkatkan peringatan → mulai dengan activeTab, lalu nilai host yang presisi untuk fitur berkelanjutan.
• Memperlakukan optional_host_permissions sebagai persetujuan otomatis → deklarasi bukanlah persetujuan pengguna → minta pada saat fitur digunakan dan tangani penolakan.
• Memeriksa izin hanya saat instalasi → pengguna dapat mencabutnya nanti → periksa sebelum bekerja dan dengarkan peristiwa penghapusan.
• Hanya meninjau perubahan kode pada upgrade → izin baru dapat menonaktifkan ekstensi → bandingkan set izin dan uji izin yang diberikan sebelumnya.
• Memperlakukan izin browser sebagai otorisasi backend → data masih dapat masuk ke akun yang salah → otorisasi ulang identitas, sumber daya, dan bidang di sisi server.
• Mengisi teks persetujuan dengan nama API → pengguna tidak dapat membentuk model risiko yang berguna → jelaskan tujuan, cakupan, dan jalan keluar.

Pertanyaan lanjutan dan jawabannya

Pertanyaan lanjutan 1: Mengapa tidak meminta <all_urls> secara langsung?

Tindakan satu kali pada halaman saat ini tidak memerlukan akses latar belakang ke setiap situs. activeTab memberikan kemampuan sementara setelah tindakan pengguna dan mengurangi paparan jangka panjang; hanya persyaratan lintas halaman berkelanjutan yang jelas yang membenarkan akses host yang presisi.

Pertanyaan lanjutan 2: Bagaimana dengan data yang sudah diunggah saat pengguna mencabut akses?

Pencabutan mencegah akses browser berikutnya tetapi tidak dapat menarik kembali data yang telah meninggalkan perangkat. Gunakan bidang minimal, retensi singkat, dan kontrol penghapusan di backend; bersihkan antrean keluar lokal dan beri tahu pengguna pemrosesan apa yang telah dilakukan.

Pertanyaan lanjutan 3: Mengapa perlu mengotorisasi ulang di backend setelah izin opsional berhasil diberikan?

Izin browser menyatakan bahwa ekstensi dapat membaca halaman, bukan bahwa pengguna dapat mengakses sumber daya bisnis. Backend harus memvalidasi sesi, versi ekstensi, sumber daya target, dan daftar izin bidang serta menolak permintaan yang usang atau anomali.

Pertanyaan lanjutan 4: Bisakah perilaku izin Chrome dan Firefox diasumsikan identik?

Tidak. Keduanya berbagi konsep WebExtensions, tetapi prompt, pola kecocokan, dan batasan runtime dapat berbeda. Uji instalasi, permintaan, pencabutan, navigasi, dan upgrade pada setiap browser target dan simpan perbedaannya dalam matriks kompatibilitas.