Belajar Shiki Rehype Pretty Code - Keamanan & Sanitasi Output

#Pendahuluan

Kode yang tampak seperti teks biasa ternyata bisa menjadi pintu masuk serangan. Jika isi code block atau meta string dirender tanpa pengamanan, karakter seperti <script> bisa lolos sebagai HTML dan mengeksekusi JavaScript di halaman pengunjung.

Episode 14 membahas keamanan dan sanitasi output: cara Shiki me-escape konten kode, bahaya meta strings yang dikontrol pengguna, penggunaan rehype-sanitize, serta penyusunan Content-Security-Policy untuk halaman hasil SSG. Keamanan bukan fitur tambahan; ini syarat produksi.

#Ancaman XSS pada Konten Kode

#Bagaimana Serangan Terjadi

Serangan XSS terjadi ketika konten pengguna dirender sebagai HTML alih-alih teks. Contoh klasik: sebuah komentar berisi kode dengan <script> yang tidak di-escape. Saat Markdown diubah menjadi HTML, tag tersebut ikut dieksekusi di browser pengunjung.

Pada pipeline highlight, risiko yang sama muncul jika isi fenced code block dimasukkan ke HTML tanpa proses escape. Untungnya, Shiki dan rehype-pretty-code menangani escape ini secara otomatis pada lapisan tokenisasi.

#Escape Bawaan Shiki

Shiki mengubah karakter berbahaya menjadi entitas HTML sebelum membungkus token dengan span. Karakter seperti <, >, dan & dirender sebagai <, >, dan &. Karena escape terjadi per token, kalian bisa yakin isi kode selalu tampil sebagai teks, apa pun yang ditulis penulis.

Mekanisme ini membuat kode dengan HTML di dalamnya, seperti snippet komponen, tetap aman dirender. Berikut contoh blok yang berisi tag HTML:

Kode berisi tag HTML

<div class="box">
  <span>Halo dunia</span>
</div>

Meski berisi tag HTML, seluruh baris di atas dirender sebagai teks berwarna karena di-escape saat tokenisasi.

#Meta Strings yang Dikontrol Pengguna

#Risiko pada Atribut

Meta string pada fenced code block diterjemahkan menjadi atribut pada elemen hasil. Jika penulis konten adalah pihak yang tidak dipercaya, meta string bisa disalahgunakan untuk menyuntikkan atribut berbahaya, misalnya onmouseover yang mengeksekusi skrip.

rehype-pretty-code memfilter meta ke set atribut yang sudah ditentukan, tetapi selalu bijak menganggap input penulis sebagai data yang tidak sepenuhnya aman. Jangan menyalurkan meta string mentah ke atribut tanpa validasi.

#Menjaga Batas Kontrol

Pisahkan dua skenario: penulis internal yang dipercaya, dan kontributor eksternal lewat CMS. Untuk skenario kedua, batasi fitur yang diizinkan pada meta string. Sebagai contoh, daftar putihkan bahasa dan nonaktifkan meta yang menambahkan atribut arbitrer:

Daftar bahasa yang diizinkan

const allowed = new Set(["ts", "js", "css", "html", "json"]);
const lang = meta.split(" ")[0].trim();
if (!allowed.has(lang)) {
  lang = "plaintext";
}

Normalisasi bahasa sebelum diteruskan ke plugin mencegah bahasa acak dari pengguna. Prinsipnya sederhana: jangan percaya input, validasi di tepi.

#Sanitasi dengan rehype-sanitize

#Memasang Sanitizer

Untuk keamanan ekstra, pasang rehype-sanitize setelah plugin highlight pada pipeline. Sanitizer ini menghapus elemen dan atribut yang tidak masuk dalam skema yang diizinkan:

npm i rehype-sanitize

Pipeline dengan sanitasi

unified()
  .use(remarkParse)
  .use(remarkRehype)
  .use(rehypePrettyCode, {
    theme: "github-dark-default",
  })
  .use(rehypeSanitize)
  .use(rehypeStringify);

Urutan penting: sanitize harus berjalan setelah plugin yang menghasilkan markup, tetapi sebelum rehypeStringify. Dengan begitu, elemen <figure>, <pre>, dan atribut data-* tetap dipertahankan selama masuk skema default.

#Menyesuaikan Skema Sanitasi

Skema default rehype-sanitize cukup ketat dan bisa menghapus atribut yang kalian butuhkan. Perluas skema untuk mempertahankan atribut code block:

Perluas skema

const schema = {
  ...defaultSchema,
  attributes: {
    ...defaultSchema.attributes,
    code: ["data-line-numbers", "data-theme"],
    figure: ["data-rehype-pretty-code-figure"],
  },
};

Atribut yang ditambahkan kembali hanya yang benar-benar dipakai. Semakin sempit skema, semakin kecil permukaan serangan.

#Content-Security-Policy

#Keunggulan Output Statis

Karena highlight berjalan di build-time, halaman hasil SSG tidak memerlukan script inline maupun evaluasi kode dinamis. Ini membuka peluang CSP yang sangat ketat. Header berikut, dengan direktif seperti script-src 'self', cocok untuk halaman yang hanya memuat aset sendiri:

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data:;
  object-src 'none';
  base-uri 'self';

Dengan script-src 'self', JavaScript hanya boleh berasal dari domain sendiri, tanpa 'unsafe-inline' dan 'unsafe-eval'. style-src 'unsafe-inline' masih diizinkan karena banyak framework menyuntikkan style dalam tag <style>.

#Menguji Kebijakan

Uji CSP sebelum diterapkan penuh. Aktifkan header dalam mode laporan terlebih dahulu menggunakan Content-Security-Policy-Report-Only, lalu pantau laporan pelanggaran di konsol. Setelah tidak ada pelanggaran, aktifkan header sebenarnya. Ingat: WASM tidak diperlukan di client pada pendekatan SSG, sehingga tidak perlu wasm-unsafe-eval.

#Penutup

Inti yang harus dibawa pulang:

• Konten kode di-escape per token sehingga aman dari XSS.
• Meta strings dari pengguna harus divalidasi dan dibatasi.
• rehype-sanitize menghapus elemen dan atribut di luar skema.
• Skema sanitasi bisa diperluas untuk atribut code block tertentu.
• Output SSG memungkinkan CSP tanpa inline script dan tanpa eval.
• Content-Security-Policy-Report-Only berguna untuk uji coba yang aman.

Di episode 15 kalian akan belajar multiple themes dark dan light: memakai objek theme seperti github-dark dan github-light, memanfaatkan CSS custom properties --shiki-dark dan --shiki-light, serta mengikuti prefers-color-scheme untuk menyesuaikan tema otomatis.