Wawancara Frontend: Bagaimana Cara Mencegah XSS dalam Aplikasi Web?

Masalah dan Kapan Ini Berlaku

Sebuah aplikasi komunitas React memiliki tiga jalur perenderan:

• Komentar biasa disimpan dalam database dan harus muncul persis sebagai teks.
• Pengumuman moderator dapat menggunakan kosakata rich-text yang terbatas: paragraf, penekanan (emphasis), daftar (list), dan tautan HTTPS.
• Halaman pencarian membaca q dari location.search dan menampilkan "Results for …" tanpa menunggu respons yang dirender server.

Sebuah tinjauan menemukan komentar biasa dan pratinjau pengumuman mengalir ke dangerouslySetInnerHTML atau innerHTML. Banner pencarian juga menggabungkan kueri ke dalam string HTML. Jelaskan cara menemukan setiap jalur source-to-sink, membedakan siklus hidup serangan, memilih encoding atau sanitasi untuk setiap konteks, dan menambahkan kontrol yang mengurangi dampak jika ada sink yang terlewat.

Jawaban dasar mencakup perenderan browser dan kepemilikan frontend. Validasi sisi server, otorisasi, dan penyimpanan konten tetap menjadi batasan yang wajib, tetapi hal tersebut tidak membuat DOM sink yang tidak aman menjadi aman. Ini adalah pertanyaan frontend karena keterampilan yang menentukan adalah memahami parsing browser, escape hatch framework, injection sink DOM, CSP, dan kontrak perenderan yang dapat diuji.

Stored, reflected, dan berbasis DOM adalah label yang berguna, tetapi mereka menggambarkan sumbu yang berbeda. "Stored" dan "reflected" menggambarkan bagaimana data yang dikendalikan penyerang mencapai korban. "Berbasis DOM" menggambarkan jalur eksekusi sisi klien di mana JavaScript memindahkan data ke dalam injection sink. Payload stored atau reflected masih dapat dieksekusi melalui DOM sink, sehingga label-label ini tidak selalu saling eksklusif.

Apa yang Dinilai oleh Pewawancara

Sinyal pertama adalah apakah kandidat menarik batasan aliran data sebelum membuat daftar header keamanan. Jawaban yang kuat mengidentifikasi sumber-sumber seperti field database, parameter URL, fragmen, postMessage, dan respons pihak ketiga, lalu mengidentifikasi sink seperti innerHTML, outerHTML, insertAdjacentHTML, document.write, eval, dan timer berbasis string. Pertanyaannya menjadi: bisakah data yang dikendalikan penyerang mencapai parser yang memperlakukannya sebagai markup, skrip, atau URL skrip?

Sinyal kedua adalah memilih pertahanan berdasarkan tipe data yang dimaksudkan. Komentar biasa adalah teks, jadi mereka harus mencapai text sink atau interpolasi JSX normal. Pengumuman kaya sengaja berisi HTML, jadi entity encoding akan merusak fitur tersebut; mereka memerlukan sanitizer HTML yang terpelihara dengan kebijakan ketat tepat sebelum batas perenderan tepercaya. Nilai URL memerlukan validasi protokol dan tujuan selain konteks output yang benar.

Sinyal ketiga adalah apakah kandidat memahami batasan framework. React melakukan escape pada interpolasi string normal, tetapi dangerouslySetInnerHTML adalah escape hatch yang eksplisit. Framework tidak dapat menyelamatkan string HTML mentah atau memvalidasi setiap URL javascript: atau data: yang diberikan ke properti berbahaya.

Sinyal terakhir adalah verifikasi berlapis. CSP dapat membatasi skrip mana yang dieksekusi, dan Trusted Types dapat membuat injection sink yang dipilih menolak string mentah. Tidak ada satu pun dari kontrol ini yang memperbaiki kebijakan sanitizer yang terlalu permisif atau fungsi kebijakan yang tidak aman. Jawaban yang kuat menghapus sink yang dapat dihindari, mempersempit sink yang tersisa, menerapkan kontrol browser, dan membuktikan hasilnya dengan tinjauan source-to-sink serta pengujian payload berbahaya.

Pertanyaan Klarifikasi Sebelum Menjawab

• Field mana yang merupakan teks dan field mana yang sengaja berisi HTML? Jika setiap field adalah teks, hapus semua

perenderan HTML mentah. Jika pengumuman memerlukan pemformatan, tentukan kebijakan tag, atribut, dan URL yang tepat sebelum memilih sanitizer.

• Siapa yang dapat menulis pengumuman? Input khusus moderator menurunkan paparan tetapi tidak menjadikannya tepercaya. Sesi

moderator yang dicuri, impor yang disusupi, migrasi, atau bug API masih dapat menyimpan konten berbahaya.

• Apakah tautan pengumuman diizinkan untuk keluar dari situs? Solusi dasar hanya mengizinkan tautan HTTPS. Mengizinkan

email, protokol kustom, gambar, video, atau frame yang disematkan memerlukan kebijakan yang lebih luas dan isolasi tambahan.

• Di mana sanitasi dilakukan saat ini? Sanitasi saat waktu penulisan (write-time) dapat menolak input buruk lebih awal, tetapi

batas perenderan masih membutuhkan jaminan bahwa setiap nilai yang mencapai sink HTML mentah telah disanitasi oleh kebijakan saat ini.

• Browser mana yang harus didukung? CSP berguna secara luas. Dukungan Trusted Types dan perilaku peluncurannya harus

diperiksa terhadap matriks browser sebenarnya; klien yang tidak didukung tetap bergantung pada sink yang aman dan sanitasi.

• Skrip pihak ketiga mana yang diperlukan? Kebijakan skrip yang ketat lebih mudah diterapkan ketika aplikasi memiliki kumpulan skrip yang kecil dan

diaudit. Pengelola tag dan cuplikan inline mengubah rencana migrasi CSP dan memperluas dampak dari setiap XSS yang berhasil.

• Apa arti "diperbaiki" secara operasional? Jawabannya harus mencakup pengujian regresi, pemantauan pelanggaran CSP,

pembaruan sanitizer, kepemilikan perubahan kebijakan, dan metode untuk menemukan sink yang baru diperkenalkan.

Kerangka Jawaban 30 Detik

"Saya akan menginventarisasi sumber yang tidak tepercaya dan sink yang dapat dieksekusi, lalu memperbaiki setiap jalur sesuai dengan tipe yang dimaksudkan dari nilai tersebut. Komentar biasa dan kueri pencarian adalah teks, sehingga interpolasi React atau textContent harus merendernya tanpa penguraian HTML. Fitur pengumuman benar-benar membutuhkan HTML terbatas, jadi saya akan mengirimkannya melalui sanitizer daftar izin (allowlist) yang terpelihara dan mengekspos satu perender rich-text yang sempit; tautan juga mendapatkan validasi protokol. Saya akan menghapus panggilan innerHTML lainnya, menerapkan CSP berbasis nonce atau hash dalam mode report-only sebelum penegakan, dan menggunakan Trusted Types jika didukung oleh matriks browser untuk menolak string mentah pada DOM sink. Terakhir, saya akan menguji payload stored, berbasis URL, markup yang salah format, event handler, SVG, dan script URL sambil memastikan bahwa pemformatan yang diizinkan tetap berfungsi."

Pembahasan Mendalam Langkah-demi-Langkah

Langkah 1: Petakan setiap source ke setiap parsing sink

Mulailah dengan tabel aliran data kecil, bukan daftar string payload:

Tinjauan repositori harus mencari sink langsung dan pembungkus (wrapper) di sekitarnya. Nama-nama seperti safeHtml bukanlah bukti; lacak nilai tersebut ke transformasi yang membuatnya. Periksa juga titik masuk tidak langsung: perender Markdown, editor rich-text, komponen pratinjau, pesan pelokalan dengan markup, panggilan parser DOM, SVG, utilitas template, cuplikan analitik, dan kode yang menyalin data URL atau pesan ke dalam halaman.

Klasifikasikan insiden setelah jalurnya diketahui:

• Komentar berbahaya yang disimpan di database dan ditampilkan ke pengguna lain memiliki siklus hidup stored.
• Parameter permintaan yang disalin ke dalam respons server langsung memiliki siklus hidup reflected.
• Kueri atau fragmen yang dibaca oleh JavaScript klien dan diteruskan ke innerHTML memiliki jalur eksekusi berbasis DOM.

Klasifikasi ini membantu respons insiden, tetapi keputusan remediasi tetap berasal dari sumber, konteks output, dan sink.

Langkah 2: Buat teks tetap menjadi teks

Komentar biasa dan label pencarian tidak memerlukan markup. Gunakan child React normal:

function CommentBody({ body }: { body: string }) {
  return <p>{body}</p>
}

function SearchSummary({ query }: { query: string }) {
  return <p>Results for “{query}”</p>
}

Di luar React, gunakan text sink:

summaryNode.textContent = query

Browser sekarang menerima data sebagai teks alih-alih menguraikannya kembali sebagai HTML. Jangan "membersihkan" string dengan regular expression lalu tetap menetapkannya ke innerHTML; penguraian HTML memiliki terlalu banyak elemen, atribut, encoding, dan aturan pemulihan input yang salah format sehingga pendekatan tersebut tidak dapat diandalkan.

Konteks tetap penting. Keamanan teks tidak secara otomatis membuat nilai aman dalam event handler, blok skrip, aturan CSS, atau URL. Hindari menempatkan nilai yang tidak tepercaya dalam konteks yang dapat dieksekusi. Ketika sebuah nilai termasuk dalam atribut yang aman, lakukan hardcode pada nama atribut dan gunakan properti framework atau setAttribute hanya setelah menerapkan validasi yang diperlukan oleh atribut tersebut.

Langkah 3: Isolasi satu fitur yang memerlukan HTML

Kebutuhan pengumuman tidak dapat menggunakan teks biasa karena pemformatan yang dipilih harus tetap ada. Tentukan kebijakan sebelum implementasi:

• Tag yang diizinkan: paragraf, strong emphasis, emphasis, daftar tak berurutan dan berurutan, item daftar, dan jangkar (anchor).
• Atribut yang diizinkan: hanya href, title, dan atribut tautan yang ditambahkan oleh perender.
• Protokol tautan yang diizinkan dalam skenario dasar: HTTPS.
• Konten yang tidak diizinkan: skrip, atribut event handler, gaya inline, frame, formulir, SVG, dan media sembarang.

Kemudian pusatkan sink HTML mentah:

function RichAnnouncement({ dirtyHtml }: { dirtyHtml: string }) {
  const cleanHtml = sanitizeRichText(dirtyHtml, RICH_TEXT_POLICY)
  return <div dangerouslySetInnerHTML={{ __html: cleanHtml }} />
}

sanitizeRichText mewakili sanitizer berbasis parser yang terpelihara yang dikonfigurasikan dengan kebijakan tersebut. OWASP merekomendasikan DOMPurify sebagai salah satu opsi. Properti keamanan berasal dari sanitizer dan konfigurasinya, bukan dari nama variabel atau tipe TypeScript.

Sanitasi tepat sebelum batas perenderan yang ditinjau. Sanitasi saat waktu penulisan dapat memberikan pemeriksaan tambahan, tetapi hanya mengandalkannya saja menyisakan celah untuk baris lama, impor, migrasi, API alternatif, dan perubahan kebijakan. Jika sistem menyimpan output yang disanitasi untuk kinerja, catat versi sanitizer dan kebijakan agar konten lama dapat diproses ulang setelah pembaruan keamanan.

Jangan memodifikasi HTML dengan penggabungan string setelah sanitasi. Menambahkan tautan, sorotan, atau pembungkus dengan mengedit string yang telah disanitasi dapat memperkenalkan kembali konstruksi yang tidak aman. Bangun UI tepercaya di luar wilayah HTML mentah, atau teruskan konten akhir melalui sanitizer lagi.

Langkah 4: Perlakukan URL sebagai input terstruktur

Sanitasi HTML harus mencakup atribut tautan, tetapi kebijakan produk juga harus eksplisit. Urai kandidat URL terhadap basis yang diketahui, periksa protokol yang dihasilkan, dan terima hanya protokol yang dibutuhkan fitur tersebut. Dalam skenario ini, hanya HTTPS yang lolos.

Melakukan encode pada URL berbahaya tidak membuat skemanya dapat diterima. Sebuah nilai dapat di-encode dengan benar untuk href dan tetap menggunakan protokol yang memuat skrip. Keputusan URL dan konteks atribut HTML adalah pemeriksaan terpisah. Untuk tautan eksternal yang dibuka di tab baru, tambahkan atribut relasi yang sesuai melalui perender; hal tersebut membatasi akses opener tetapi tidak menggantikan pencegahan XSS.

Hindari URL skrip yang dikendalikan pengguna sepenuhnya. eval, Function, setTimeout berbasis string, setInterval berbasis string, dan konstruksi sumber skrip dinamis tidak boleh menerima nilai yang tidak tepercaya. Jalur-jalur ini memerlukan penghapusan atau pemetaan kecil yang telah ditentukan sebelumnya, bukan sanitizer serbaguna.

Langkah 5: Tambahkan CSP sebagai lini pertahanan kedua

CSP dapat membatasi eksekusi skrip jika ada sink yang terlewat. Utamakan header respons dan rancang kebijakan di sekitar sumber daya aplikasi yang sebenarnya. Arah yang disederhanakan adalah:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{per-response-random-value}';
  object-src 'none';
  base-uri 'none'

Nonce harus tidak dapat ditebak dan unik per respons, dan hanya skrip yang disetujui yang menerimanya. Kebijakan berbasis hash dapat cocok untuk konten inline yang stabil. Hindari melemahkan kebijakan dengan daftar host yang luas atau unsafe-inline hanya untuk membungkam pelanggaran.

Mulailah dengan Content-Security-Policy-Report-Only, kumpulkan pelanggaran, hapus kode inline yang tidak terduga, lalu terapkan (enforce). Mode report-only memberikan bukti penerapan tetapi tidak memblokir apa pun. CSP tetap menjadi pertahanan berlapis (defense in depth): skrip yang diizinkan tetap memiliki hak istimewa halaman, dukungan browser berbeda berdasarkan fitur, dan kebijakan yang permisif dapat membiarkan eksploitasi asli tetap berfungsi.

Langkah 6: Gunakan Trusted Types untuk membatasi injeksi DOM

Jika didukung, tambahkan direktif CSP:

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-rich-text

Penegakan membuat injection sink DOM yang tercakup menolak string biasa. Aplikasi hanya membuat kebijakan yang dinamai, dan kebijakan tersebut mendelegasikan pembuatan HTML ke sanitizer yang disetujui. Ini mengubah penetapan tidak aman yang diam-diam menjadi pengecualian yang terlihat dan membuat sink string mentah baru lebih mudah ditangkap dalam pengujian dan pemantauan.

Kebijakan yang mengembalikan input tanpa perubahan menggagalkan kontrol ini. Kebijakan default yang luas juga dapat menyembunyikan jalur lawas dengan mengonversi setiap string secara otomatis. Gunakan kebijakan default untuk sementara selama migrasi untuk diagnostik, lalu pindahkan pemanggil ke nilai tepercaya eksplisit dan hapus sink yang dapat dihindari.

Trusted Types tidak mencakup setiap kemungkinan cara untuk mengeksekusi kode, dan browser lama mungkin tidak memiliki penegakan ini. Garis dasarnya tetaplah perenderan yang aman, sanitasi sempit, validasi URL, dan penghapusan API string yang dapat dieksekusi.

Langkah 7: Kurangi dampak di luar fungsi perenderan

Cookie sesi biasanya harus menggunakan HttpOnly, Secure, dan kebijakan SameSite yang sesuai. HttpOnly dapat menghentikan JavaScript yang disuntikkan agar tidak membaca cookie tersebut secara langsung, tetapi XSS yang aktif masih dapat mengirim permintaan sebagai pengguna atau membaca data yang tersedia di halaman. Atribut cookie mengurangi dampak; mereka tidak menutup jalur injeksi.

Otorisasi server harus melindungi setiap tindakan sensitif bahkan ketika frontend menyembunyikan kontrol. Lakukan sanitasi atau validasi pada batasan server jika sesuai, dan pertahankan input penyerang yang disimpan tetap diberi label sebagai tidak tepercaya. Skrip pihak ketiga dieksekusi dengan hak istimewa halaman, jadi kurangi jumlahnya, batasi cakupannya ke rute yang diperlukan, audit pembaruan, dan sertakan dalam desain CSP.

Langkah 8: Verifikasi keamanan dan pemformatan yang dimaksudkan

Bangun korpus pengujian yang mencakup berbagai jalur parser:

<img src=x onerror=alert(1)>
<a href="javascript:alert(1)">open</a>
<svg onload=alert(1)></svg>
"><script>alert(1)</script>
malformed tags and mixed character encodings

Gunakan callback pengujian inert dalam lingkungan pengujian yang terisolasi daripada perilaku destruktif yang sebenarnya. Verifikasi:

1. Komentar biasa menampilkan setiap karakter dan tidak membuat elemen apa pun.
2. Parameter pencarian tetap berupa teks setelah navigasi normal, URL yang di-encode, riwayat browser, dan hidrasi.
3. Tag pengumuman yang diizinkan tetap bertahan sementara skrip, event handler, gaya, SVG, frame, dan URL yang tidak aman

dihapus.

1. Output sanitizer tidak dimutasi sebelum mencapai sink HTML mentah.
2. Telemetri CSP report-only dipahami, lalu penegakan memblokir sink pengujian yang sengaja dimasukkan.
3. Penegakan Trusted Types melempar error pada string mentah dan hanya menerima output kebijakan yang telah disanitasi dan disetujui.
4. Fixture rich-text yang ada, tautan, struktur pembaca layar, dan perilaku salin-tempel tetap berfungsi.

Tambahkan tinjauan statis untuk sink baru, pengujian unit untuk kebijakan sanitizer, pengujian integrasi untuk setiap jalur perenderan, dan pengujian browser terhadap matriks yang didukung. Jaga agar sanitizer tetap diperbarui dan jalankan kembali korpus berbahaya ketika browser, framework, sanitizer, editor, atau kebijakan berubah.

Contoh Jawaban Berkualitas Tinggi

"Pertama, saya akan mengidentifikasi sumber yang tidak tepercaya dan API browser yang menguraikannya. Isi komentar database, HTML pengumuman, dan q dari location.search adalah sumbernya. innerHTML, dangerouslySetInnerHTML, dan konstruktor skrip atau URL skrip apa pun adalah sink yang akan saya lacak.

Komentar dan banner pencarian adalah fitur teks. Saya akan merendernya sebagai child React atau menetapkan textContent, sehingga browser tidak pernah menginterpretasikan karakternya sebagai markup. Pengumuman memiliki kontrak yang berbeda karena mengizinkan HTML terbatas. Saya akan menentukan daftar izin kecil untuk paragraf, penekanan, daftar, dan tautan HTTPS, meneruskan nilai akhir melalui sanitizer berbasis parser yang terpelihara, dan mempertahankan satu komponen HTML mentah yang ditinjau. Sanitizer juga akan menghapus event handler, gaya, SVG, frame, dan skema URL yang tidak aman. Tidak ada kode yang akan menggabungkan markup setelah langkah tersebut.

Saya akan menggambarkan komentar berbahaya yang disimpan sebagai siklus hidup stored dan jalur kueri pencarian sebagai berbasis DOM. Jika server menyalin nilai permintaan ke dalam respons HTML langsungnya, itu akan menjadi reflected. Label-label ini membantu menemukan paparan, sedangkan perbaikan tetap berasal dari konteks output dan sink.

Untuk pertahanan berlapis, saya akan meluncurkan CSP berbasis nonce atau hash melalui mode report-only, menghapus pelanggaran, lalu menegakkannya. Jika dukungan browser kami memungkinkannya, saya akan mewajibkan Trusted Types untuk sink skrip dan hanya mengizinkan kebijakan bernama yang memanggil sanitizer yang disetujui. Saya tidak akan menggunakan CSP, cookie HttpOnly, atau kebijakan Trusted Types yang mengembalikan input tanpa perubahan sebagai perbaikan utama.

Verifikasi saya akan mencakup payload stored, payload URL, markup yang salah format, atribut event, SVG, dan URL skrip. Saya akan memastikan bahwa jalur teks tidak membuat elemen apa pun, pemformatan yang diizinkan bertahan, konten yang tidak diizinkan dihapus, penetapan string mentah gagal di bawah Trusted Types, dan CSP yang ditegakkan memblokir sink pengujian yang sengaja dimasukkan. Saya juga akan menjaga sanitizer tetap diperbarui dan menjadikan sink injeksi baru sebagai titik pemeriksaan tinjauan kode dan analisis statis."

Kesalahan Umum

• Melakukan escape pada setiap nilai dengan cara yang sama → browser menguraikan HTML, atribut, URL, CSS, dan JavaScript di bawah aturan yang berbeda → jauhkan data dari konteks yang dapat dieksekusi dan terapkan pertahanan yang diperlukan oleh sink yang tepat.
• Mengirim teks biasa melalui innerHTML setelah menghapus tag skrip → atribut event, markup yang salah format, SVG, skema URL, dan perilaku parser tetap ada → ganti sink dengan perenderan teks JSX atau textContent.
• Melakukan encode pada rich text → markup muncul secara harfiah dan fitur menjadi rusak → gunakan sanitizer HTML yang terpelihara dengan daftar izin yang sempit ketika HTML merupakan persyaratan produk yang eksplisit.
• Mempercayai konten khusus moderator → akun yang disusupi, impor, migrasi, dan cacat API dapat menyimpan markup berbahaya → perlakukan konten yang disimpan sebagai tidak tepercaya pada batas perenderan.
• Melakukan sanitasi lalu menggabungkan lebih banyak HTML → mutasi selanjutnya dapat membuat ulang konstruksi yang dapat dieksekusi → jadikan sanitasi sebagai transformasi akhir sebelum sink yang ditinjau.
• Memvalidasi href hanya dengan encoding HTML → nilai yang di-encode masih dapat membawa protokol yang tidak dapat diterima → urai URL dan izinkan hanya skema dan tujuan yang diperlukan.
• Memperlakukan auto-escaping React sebagai sesuatu yang universal → escape hatch dan API DOM langsung melewati interpolasi string normal → inventarisasi setiap jalur HTML mentah dan string yang dapat dieksekusi.
• Hanya mengandalkan CSP saja → kebijakan yang lemah, skrip yang diizinkan, atau fitur yang tidak didukung dapat membiarkan sink dapat dieksploitasi → hapus sink yang tidak aman terlebih dahulu dan gunakan CSP sebagai penghalang tambahan.
• Membuat kebijakan Trusted Types yang mengembalikan inputnya → browser melihat objek tepercaya tanpa transformasi yang layak dipercaya → batasi nama kebijakan dan delegasikan ke sanitizer yang ditinjau.
• Hanya memeriksa bahwa payload alert telah berhenti → satu payload tidak mencakup skema URL, markup yang salah format, elemen alternatif, atau regresi dalam pemformatan yang diizinkan → pertahankan korpus berbahaya yang bervariasi dan fixture rich-text positif.

Pertanyaan Lanjutan

Pertanyaan Lanjutan 1: Bagaimana Anda memigrasikan aplikasi lawas dengan ratusan penetapan innerHTML?

Inventarisasi sink dan beri peringkat berdasarkan sumber tidak tepercaya yang dapat dijangkau, paparan pengguna, dan hak istimewa. Ganti jalur khusus teks terlebih dahulu. Perkenalkan satu batas rich-text yang ditinjau untuk sisa HTML yang sah. Terapkan CSP dan Trusted Types dalam mode report-only atau diagnostik untuk mengungkap jalur runtime yang terlewat oleh pencarian statis. Kebijakan default Trusted Types sementara dapat mencatat panggilan lawas, tetapi tidak boleh secara diam-diam menyetujui string yang tidak berubah; migrasikan pemanggil ke kebijakan eksplisit dan hapus jalur kompatibilitas sementara tersebut.

Pertanyaan Lanjutan 2: Apa yang berubah jika pengumuman harus mengizinkan gambar dan video yang disematkan?

Kontrak kepercayaan meluas. Tentukan origin gambar yang diizinkan, skema URL, dimensi, perilaku pemuatan, dan aturan privasi. Melakukan proxy pada gambar dapat mengurangi permintaan langsung pihak ketiga. Video yang disematkan harus menggunakan daftar izin penyedia yang kecil dan frame yang di-sandbox dengan kemampuan yang diperlukan saja. Kebijakan sanitizer, direktif CSP, perilaku persetujuan, dan korpus pengujian semuanya berubah. Frame, gaya, dan HTML penyedia yang sembarangan tidak boleh masuk ke dalam perender pengumuman yang ada.

Pertanyaan Lanjutan 3: Bagaimana jika CSP yang ketat merusak skrip analitik dan tag manager?

Jalankan kebijakan yang diusulkan dalam mode report-only dan klasifikasikan setiap pelanggaran berdasarkan pemilik bisnis dan tujuan skrip. Hapus skrip yang tidak digunakan, ganti cuplikan inline dengan modul eksternal yang disetujui, dan berikan skrip yang diperlukan nonce per respons atau hash stabil yang sesuai. Wildcard yang luas atau unsafe-inline memulihkan kompatibilitas dengan mengorbankan sebagian besar batas keamanan. Jika pengelola tag dapat menyuntikkan skrip sembarangan, dokumentasikan bahwa itu tetap menjadi jalur kode yang memiliki hak istimewa dan batasi siapa yang dapat mempublikasikannya melaluinya.

Pertanyaan Lanjutan 4: Server sudah melakukan sanitasi pada pengumuman. Mengapa tetap mempertahankan batasan frontend?

Komponen HTML mentah memerlukan kontrak input yang dapat diverifikasi di mana pun transformasi dijalankan. API alternatif, baris lama, impor, entri cache, migrasi, atau kebijakan yang diubah dapat melewati asumsi write-time. Enkapsulasi sink sehingga pemanggil hanya dapat memberikan output dari sanitizer saat ini, uji kontrak tersebut, dan beri versi pada konten yang disanitasi yang disimpan jika digunakan kembali. Pemeriksaan server mengurangi data buruk yang masuk ke sistem; batas perenderan mencegah nilai yang belum diverifikasi mencapai parser.

Pertanyaan Lanjutan 5: Bagaimana Anda menyelidiki laporan XSS di produksi?

Pertahankan URL yang dilaporkan, pengidentifikasi konten, browser, laporan CSP, dan versi penerapan yang relevan tanpa mengeksekusi payload di akun normal. Reproduksi di lingkungan yang terisolasi, lacak jalur source-to-sink yang tepat, dan tentukan apakah payload tersebut disimpan (stored), didorong oleh permintaan (request-driven), atau disediakan oleh pihak ketiga. Hapus atau nonaktifkan jalur perenderan yang rentan, batalkan konten berbahaya yang disimpan jika perlu, lakukan rotasi kredensial yang terekspos, tinjau tindakan sensitif yang dilakukan selama jendela paparan, lalu tambahkan kelas payload ke korpus regresi sebelum memulihkan fitur tersebut.