Perintah dan konteks
Sebuah produk SaaS menambahkan rich text buatan pengguna ke komentar, basis pengetahuan, dan templat. Tim ingin menggunakan HTML Sanitizer API bawaan peramban untuk mengurangi aturan pemfilteran kustom, tetapi API tersebut belum tersedia di beberapa peramban utama. Tentukan apakah akan mengadopsinya dan jelaskan trade-off dari segi keamanan, pengalaman, kompatibilitas, dan operasional.
Hal yang dievaluasi pewawancara
- Apakah Anda menentukan model ancaman, konten yang diizinkan, dan batas kepercayaan server terlebih dahulu.
- Apakah Anda membedakan
setHTML(), konfigurasi Sanitizer kustom,setHTMLUnsafe(), dan Trusted Types. - Apakah cakupan peramban, implementasi fallback, konsistensi konten, dan biaya migrasi dikuantifikasi.
- Apakah metrik bertahap memvalidasi risiko XSS, keberhasilan pengeditan, performa, dan kesiapan rollback.
Pertanyaan klarifikasi yang perlu diajukan
Konfirmasikan apakah rich text memerlukan tautan, gambar, tabel, sematan (embed), gaya, atau atribut kustom; apakah konten dirender di sisi server, diekspor ke email, diindeks untuk pencarian, atau digunakan kembali pada klien lain. Konfirmasikan peramban yang didukung, sanitizer yang ada, kebutuhan kepatuhan, attack surface, dan penurunan fitur yang dapat diterima.
Jawaban 30 detik
Saya akan menggunakan fallback berbasis kapabilitas bertingkat, mengutamakan native (native-first), dan divalidasi oleh server, alih-alih mengganti sanitizer yang ada secara langsung sekaligus. setHTML() native mengikuti jalur sanitasi yang aman, tetapi cakupannya terbatas, sehingga peramban yang tidak didukung menggunakan kebijakan setara yang telah diaudit. Mulailah dengan area berisiko rendah seperti komentar dan ukur pemblokiran payload berbahaya, fidelitas konten, keberhasilan pengeditan, latensi, serta distribusi peramban. Server tetap melakukan sanitasi dan encoding pada batas output; Trusted Types menambahkan batasan di sekitar injection sink.
Pembahasan mendalam langkah demi langkah
1. Menentukan nilai pengguna dan model ancaman
Nilai bagi pengguna adalah konten berformat yang andal; risiko utamanya adalah mengirimkan HTML yang tidak tepercaya ke DOM atau rendering sink lainnya. Tentukan elemen, atribut, skema URL, dan sumber media yang diizinkan sebelum memutuskan kapabilitas mana yang sebanding dengan biaya pemeliharaannya.
2. Memisahkan kapabilitas API native
Element.setHTML() dan Document.parseHTML() menggunakan pengaturan default sanitasi yang aman; konfigurasi kustom dapat memperketat daftar izin (allowlist). setHTMLUnsafe() ditujukan untuk kasus yang memerlukan struktur khusus, tetapi membutuhkan konfigurasi dan peninjauan yang ketat. Spesifikasi ini mewajibkan metode yang aman untuk menghapus markup yang dapat mengeksekusi skrip, sehingga API ini bukan izin untuk sembarang HTML.
3. Mengevaluasi cakupan dan fallback
MDN melabeli HTML Sanitizer API sebagai Ketersediaan terbatas (Limited availability). Lakukan feature-detection pada jalur native dan pilih jalur server atau pustaka yang diaudit jika tidak didukung. Bagikan daftar izin, test fixture, dan catatan versi di kedua jalur. Fallback harus membuang kapabilitas berisiko tinggi daripada melonggarkan kebijakan demi kesamaan visual.
4. Merancang kontrak konten lintas klien
Simpan input asli dan representasi aman yang dinormalisasi, tentukan representasi mana yang digunakan untuk pengeditan, pratinjau, email, pencarian, dan ekspor. Validasi ulang di setiap batas output server. Sanitasi di sisi klien mengurangi risiko injeksi DOM; ini tidak menggantikan otorisasi, penyimpanan, atau kebijakan rendering di sisi server.
5. Merancang peluncuran bertahap dan metrik
Aktifkan satu jenis konten untuk kelompok tenant kecil dan bandingkan temuan antara native dan fallback. Lacak pemblokiran payload berbahaya, keluhan atas penghapusan yang tidak diinginkan, keberhasilan pengiriman editan, latensi render pertama dan input, cakupan peramban, konsistensi versi kebijakan, serta insiden keamanan.
6. Menangani Trusted Types dan operasional
Aktifkan pelaporan atau penegakan Trusted Types untuk sink berisiko tinggi, mewajibkan fungsi kebijakan mengembalikan tipe yang telah divalidasi. Tetapkan persetujuan perubahan aturan, uji regresi terhadap fixture berbahaya, pemrosesan ulang konten, dan rollback darurat. Jangan biarkan pembaruan peramban mengubah kebijakan keamanan secara diam-diam.
Contoh jawaban berkualitas tinggi
Saya akan menempatkan kapabilitas konten, model ancaman, dan lingkungan runtime ke dalam tiga tabel keputusan. HTML Sanitizer API berguna untuk pembersihan terstruktur di sisi klien sebelum HTML yang tidak tepercaya masuk ke DOM; setHTML() memiliki default yang aman dan spesifikasi WHATWG mengurangi kemungkinan markup berkemampuan skrip dipertahankan, tetapi MDN masih menandai cakupannya sebagai terbatas. Rencana produknya adalah mengutamakan native dengan fallback ke pustaka matang atau kebijakan server, berbagi elemen, atribut, skema, dan fixture yang diizinkan. Server menyimpan representasi asli dan aman serta memvalidasi secara terpisah untuk halaman, email, pencarian, dan ekspor; pembersihan di sisi klien tidak menyediakan otorisasi atau perlindungan XSS yang lengkap. Luncurkan fitur komentar terlebih dahulu dan ukur pemblokiran, fidelitas, keberhasilan pengiriman, performa, distribusi peramban, dan insiden keamanan. Gunakan setHTMLUnsafe() hanya untuk kebutuhan struktur yang benar-benar dapat dijustifikasi dengan konfigurasi ketat, Trusted Types, dan peninjauan. Jalankan ulang fixture berbahaya historis setelah pembaruan kebijakan dan segera lakukan rollback jika terjadi regresi.
Kesalahan umum
- Menganggap bahwa API peramban native menghilangkan kebutuhan akan sanitasi di sisi server.
- Hanya menguji demo dan mengabaikan peramban yang tidak didukung serta konsistensi fallback.
- Melonggarkan konfigurasi
setHTMLUnsafe()untuk mempertahankan sematan sembarang. - Mengganti metrik fidelitas, penghapusan yang tidak diinginkan, dan metrik keamanan hanya dengan satu angka keberhasilan filter.
- Memperlakukan Trusted Types sebagai sanitizer, atau memperlakukan sanitizer sebagai otorisasi.
Pertanyaan lanjutan dan tanggapan
Mengapa tidak mengalihkan setiap permukaan ke API native dengan segera?
Cakupan, kapabilitas konten, dan migrasi data lama masih belum pasti. Peluncuran yang dapat dibatalkan (reversible) dengan fallback memvalidasi peramban nyata dan distribusi konten terlebih dahulu.
Bagaimana jika kebijakan native dan server berbeda?
Bagikan daftar izin dan fixture berbahaya yang diberi versi, dengan server sebagai batas akhir. Catat versi kebijakan dan sampel saat klien menemukan perbedaan; jangan pernah melonggarkan aturan secara diam-diam.
Kapan penegakan Trusted Types layak untuk diaktifkan?
Setelah sink utama diinventarisasi, fungsi kebijakan dan komponen pihak ketiga dimigrasikan, serta mode hanya-lapor menunjukkan positif palsu yang rendah, aktifkan penegakan secara bertahap.