Apa Itu SSRF? Bahaya dan Cara Mencegahnya

Kalau kamu pernah bikin fitur upload gambar dari URL, image proxy, webhook, atau fitur "preview link" di aplikasi web, ada kemungkinan besar kamu sudah menyentuh area yang rawan disusupi Server-Side Request Forgery (SSRF) tanpa sadar. SSRF ini salah satu kerentanan yang sering diremehkan karena kelihatannya "cuma fitur fetch URL biasa," padahal dampaknya bisa sampai ke pencurian kredensial cloud, akses ke sistem internal, sampai eksekusi kode dari jarak jauh. Di artikel ini, Teman-Teman bakal diajak kenalan sama SSRF dari konsep dasar, lihat contoh kode yang rentan, praktik langsung cara mengeksploitasi dan menambalnya, sampai ngobrolin strategi pencegahan yang beneran dipakai di industri.

Apa Itu Server-Side Request Forgery (SSRF)?

Server-Side Request Forgery (SSRF) adalah kerentanan keamanan yang bikin server sebuah aplikasi "dipaksa" mengirim permintaan (request) ke tujuan yang sebenarnya tidak diinginkan, biasanya atas perintah pengguna yang tidak berwenang.

Simpelnya begini: aplikasi kamu punya fitur yang mengambil data dari URL yang diberikan pengguna, lalu server-lah yang benar-benar melakukan request itu, bukan browser pengguna. Karena request-nya berasal dari server, dia otomatis dianggap "orang dalam" oleh jaringan, firewall, atau sistem lain di sekitarnya. Nah, celah inilah yang dimanfaatkan penyerang.

MITRE mengklasifikasikan SSRF sebagai CWE-918, dan kerentanan ini masuk dalam kategori resmi OWASP Top 10 2021 sebagai A10. Menariknya, walau tingkat kemunculannya di data OWASP tergolong rendah, potensi dampak dan tingkat kesulitan eksploitasinya justru di atas rata-rata dibanding kerentanan lain. Artinya, jarang ditemukan tapi kalau ketemu, efeknya bisa parah.

Kalau mau bandingkan dengan kerentanan lain yang mirip-mirip, Cross-Site Request Forgery (CSRF) memanfaatkan browser korban sebagai "kaki tangan," sedangkan SSRF memanfaatkan server aplikasi itu sendiri sebagai kaki tangannya. Bedanya jauh dari sisi dampak, karena server biasanya punya akses jaringan yang jauh lebih luas dibanding browser pengguna biasa.

Kenapa SSRF Ini Bahaya Banget buat Aplikasi dan Bisnis

Banyak yang mengira SSRF cuma soal "bisa akses localhost doang." Padahal kalau digali lebih dalam, dampaknya bisa berlapis-lapis. Berikut beberapa risiko konkret yang sering muncul di laporan bug bounty maupun insiden nyata:

• Kebocoran data sensitif lewat akses ke file lokal (file://) atau layanan internal yang harusnya tidak bisa diakses dari luar.

• Pencurian kredensial cloud lewat endpoint metadata seperti http://169.254.169.254/, yang biasa dipakai AWS, GCP, dan Azure untuk menyimpan token sementara instance.

• Pemetaan jaringan internal alias port scanning, di mana penyerang bisa tahu port dan layanan apa saja yang aktif di jaringan privat perusahaan.

• Bypass firewall dan access control list (ACL), karena request datang dari server yang dipercaya, bukan dari IP luar yang biasanya diblok.

• Eskalasi ke Remote Code Execution (RCE), kalau layanan internal yang diakses ternyata punya kerentanan sendiri, misalnya Redis atau OGNL injection di Confluence.

• Denial of Service (DoS), dengan membanjiri layanan internal yang biasanya dikonfigurasi untuk trafik rendah.

Yang bikin SSRF makin berbahaya di era sekarang adalah arsitektur cloud. Dulu, kalau server "di dalam" jaringan, biasanya dianggap aman. Sekarang, dengan IAM role, service mesh, dan microservices yang saling terhubung lewat HTTP, satu celah SSRF bisa jadi pintu masuk ke banyak sistem sekaligus.

Studi Kasus: Bagaimana SSRF Menjatuhkan Capital One

Salah satu contoh paling sering dikutip di dunia keamanan siber adalah insiden Capital One tahun 2019. MUGHU sengaja angkat kasus ini karena ceritanya jadi pelajaran yang gampang dipahami tentang kenapa SSRF nggak boleh dianggap remeh.

Latar belakang: Capital One menjalankan sebagian infrastrukturnya di AWS, dengan sebuah Web Application Firewall (WAF) yang berjalan di atas instance EC2.

Masalahnya: WAF tersebut dikonfigurasi secara keliru sehingga rentan terhadap SSRF. Penyerang berhasil memanfaatkan celah ini untuk mengirim request dari server WAF ke endpoint metadata AWS di 169.254.169.254.

Pendekatan penyerang: Lewat SSRF itu, penyerang mendapatkan kredensial sementara dari IAM role yang melekat pada instance tersebut. Masalahnya, role itu punya izin akses yang jauh lebih luas dari yang seharusnya, termasuk akses ke banyak bucket S3.

Hasilnya: Data pribadi lebih dari 100 juta pelanggan Capital One bocor, termasuk nomor Social Security dan skor kredit, dengan volume sekitar 30 GB data aplikasi kredit. Capital One akhirnya kena denda 80 juta dolar AS dari regulator dan membayar 190 juta dolar untuk menyelesaikan gugatan class action.

Pelajaran kuncinya: Satu kerentanan SSRF, kalau ketemu dengan konfigurasi IAM yang kebablasan dan metadata service yang tidak dilindungi, bisa berubah jadi bencana skala besar. Ini juga alasan kenapa sekarang AWS mendorong penggunaan IMDSv2 yang mewajibkan token sesi, bukan lagi IMDSv1 yang bisa diakses lewat request GET biasa.

Cara Kerja SSRF: Dari Permintaan Biasa Jadi Serangan

Supaya lebih kebayang, coba bandingkan dua kondisi berikut.

Kondisi normal, aplikasi belanja online punya fitur cek stok barang di gudang tertentu:

POST /produk/stok HTTP/1.0
Content-Type: application/x-www-form-urlencoded

stockApi=http://gudang.tokokita.com:8080/stok/cek?produkId=6&gudangId=1

Server menerima URL itu, mengambil datanya, lalu mengembalikan hasilnya ke pengguna. Sejauh ini normal.

Kondisi diserang, penyerang mengganti nilai stockApi dengan URL lain:

POST /produk/stok HTTP/1.0
Content-Type: application/x-www-form-urlencoded

stockApi=http://localhost/admin

Kalau server tidak memvalidasi tujuan URL, dia akan tetap mengeksekusi request ke localhost/admin dan mengembalikan isinya. Padahal halaman admin itu biasanya cuma bisa diakses dari jaringan internal atau oleh pengguna yang sudah login. Karena request-nya "keluar" dari server itu sendiri, banyak sistem yang secara default mempercayainya begitu saja.

Ini yang bikin SSRF licik: penyerang tidak langsung menyerang sistem target, tapi meminjam "identitas" server aplikasi yang sudah dipercaya oleh sistem lain di sekitarnya.

Prasyarat Sebelum Praktik

Sebelum masuk ke bagian praktik, siapkan dulu beberapa hal ini biar prosesnya lancar:

• Node.js versi 18 ke atas terpasang di komputer kamu, karena contoh kode di sini pakai Express dan fetch bawaan Node.

• Pemahaman dasar soal HTTP request, terutama method GET dan POST.

• Terminal atau command line yang nyaman kamu pakai sehari-hari.

• Editor kode seperti VS Code.

• Lingkungan uji coba lokal saja. Jangan pernah mempraktikkan eksploitasi ini ke server milik orang lain tanpa izin tertulis, karena itu masuk kategori pelanggaran hukum di hampir semua negara termasuk Indonesia lewat UU ITE.

Kenapa poin terakhir ini penting banget MUGHU tekankan? Karena tujuan artikel ini murni edukasi keamanan defensif. Konsep yang sama yang dipakai buat menyerang, dipakai juga buat mendeteksi dan menambal celah di aplikasi kamu sendiri.

Baca juga Bug Bounty: Panduan Lengkap Menjadi Hacker di Indonesia

Step 1: Bikin Aplikasi Contoh yang Rentan SSRF

Kita mulai dengan bikin server Express sederhana yang punya fitur "ambil gambar profil dari URL," fitur yang gampang banget kena SSRF kalau tidak divalidasi.

Bikin folder proyek dan install dependensi:

mkdir demo-ssrf
cd demo-ssrf
npm init -y
npm install express

Kenapa langkah ini penting? Karena struktur proyek yang rapi memudahkan kamu membedakan kode yang rentan dan kode yang sudah diperbaiki nanti, jadi perbandingannya jelas.

Buat file server.js:

const express = require("express");
const app = express();

// ⚠️ Endpoint ini RENTAN SSRF, jangan dipakai di produksi
app.get("/fetch-image", async (req, res) => {
  const target = req.query.url;
  try {
    const response = await fetch(target, { redirect: "follow" });
    const contentType = response.headers.get("content-type") || "text/plain";
    const body = await response.text();
    res.type(contentType).send(body);
  } catch (err) {
    res.status(500).send("Gagal mengambil URL: " + err.message);
  }
});

app.listen(3000, () => console.log("Server jalan di http://localhost:3000"));

Jalankan servernya:

node server.js

Output yang diharapkan:

Server jalan di http://localhost:3000

Kenapa kode di atas rentan? Karena target diambil langsung dari input pengguna lewat query parameter url, lalu langsung di-fetch tanpa validasi sama sekali. Server percaya begitu saja apa pun yang dikirim pengguna sebagai tujuan request.

Step 2: Coba Eksploitasi SSRF di Localhost

Sekarang, coba akses endpoint itu dengan URL yang wajar dulu, untuk memastikan fiturnya berfungsi:

curl "http://localhost:3000/fetch-image?url=https://example.com"

Setelah itu, coba arahkan ke alamat internal server itu sendiri:

curl "http://localhost:3000/fetch-image?url=http://127.0.0.1:3000/fetch-image?url=https://example.com"

Kalau di lingkungan kamu ada layanan lain yang berjalan di port berbeda, misalnya panel admin di port 5000, coba juga:

curl "http://localhost:3000/fetch-image?url=http://127.0.0.1:5000/admin"

Kenapa langkah ini penting? Ini membuktikan bahwa server kamu bisa dipaksa "menghubungi dirinya sendiri" atau layanan lain yang seharusnya tidak bisa diakses langsung dari internet. Inilah inti dari SSRF terhadap server itu sendiri (server-side attack), sesuai penjelasan yang juga dibahas panjang lebar oleh PortSwigger dalam materi pembelajaran keamanan web mereka.

Step 3: Akses Layanan Internal Lewat SSRF

Selanjutnya, mari simulasikan skenario yang lebih realistis: layanan internal yang seharusnya tidak boleh diakses dari luar. Buat file internal-admin.js terpisah untuk mensimulasikan panel admin internal:

const express = require("express");
const app = express();

app.get("/admin/users", (req, res) => {
  res.json([
    { id: 1, nama: "Budi", role: "admin" },
    { id: 2, nama: "Sari", role: "user" },
  ]);
});

app.listen(5000, () => console.log("Panel admin internal jalan di port 5000"));

Jalankan di terminal terpisah:

node internal-admin.js

Sekarang coba akses panel admin itu lewat celah SSRF di server utama:

curl "http://localhost:3000/fetch-image?url=http://127.0.0.1:5000/admin/users"

Output yang diharapkan kurang lebih seperti ini:

[
  { "id": 1, "nama": "Budi", "role": "admin" },
  { "id": 2, "nama": "Sari", "role": "user" }
]

Kalau kamu berhasil melihat data ini padahal server "panel admin" tadi cuma didengarkan di 127.0.0.1 (artinya harusnya cuma bisa diakses dari mesin yang sama), berarti kamu baru saja membuktikan sendiri bagaimana SSRF membobol batas jaringan internal lewat server yang dipercaya.

Step 4: Kenali Jenis-Jenis SSRF (Basic, Blind, Time-Based)

Sebelum lanjut ke perbaikan, penting buat kenalan dulu sama tiga variasi SSRF, karena strategi mendeteksinya beda-beda:

1. Basic atau Full Response SSRF — respons dari server internal langsung dikembalikan ke penyerang, seperti contoh Step 3 di atas. Ini paling gampang dideteksi karena hasilnya kelihatan langsung.

2. Blind SSRF — server memang melakukan request ke tujuan yang dimanipulasi, tapi hasilnya tidak dikembalikan ke pengguna. Penyerang harus menyimpulkan keberhasilan lewat sinyal tidak langsung, misalnya DNS lookup ke server yang mereka kontrol.

3. Time-Based Blind SSRF — penyerang mengandalkan selisih waktu respons untuk menebak port atau host mana yang aktif di jaringan internal, mirip teknik port scanning tapi lewat celah aplikasi.

Blind SSRF ini yang paling sering luput dari pengujian keamanan biasa, karena aplikasi kelihatan "aman-aman saja" dari luar padahal sebenarnya tetap melakukan request berbahaya di baliknya.

Step 5: Perbaiki Kerentanan dengan Validasi dan Allowlist

Sekarang bagian yang paling penting: menambal celahnya. Ganti kode di server.js dengan versi yang sudah divalidasi:

Baca juga Apa Itu WAF? Panduan Lengkap Web Application Firewall

const express = require("express");
const dns = require("dns").promises;
const net = require("net");
const app = express();

const ALLOWED_HOSTS = ["images.tokokita.com", "cdn.tokokita.com"];

function isPrivateIp(ip) {
  return (
    net.isIP(ip) &&
    (/^10\./.test(ip) ||
      /^127\./.test(ip) ||
      /^192\.168\./.test(ip) ||
      /^169\.254\./.test(ip) ||
      /^172\.(1[6-9]|2\d|3[0-1])\./.test(ip))
  );
}

app.get("/fetch-image", async (req, res) => {
  let target;
  try {
    target = new URL(req.query.url);
  } catch {
    return res.status(400).send("URL tidak valid");
  }

  // 1. Hanya izinkan skema https
  if (target.protocol !== "https:") {
    return res.status(400).send("Skema URL tidak diizinkan");
  }

  // 2. Cocokkan hostname dengan allowlist
  if (!ALLOWED_HOSTS.includes(target.hostname)) {
    return res.status(400).send("Host tidak ada di daftar yang diizinkan");
  }

  // 3. Resolve DNS dan cek apakah IP-nya privat (mencegah DNS rebinding)
  const { address } = await dns.lookup(target.hostname);
  if (isPrivateIp(address)) {
    return res.status(400).send("Alamat tujuan tidak diizinkan");
  }

  try {
    const response = await fetch(target.toString(), { redirect: "manual" });
    if (response.status >= 300 && response.status < 400) {
      return res.status(400).send("Redirect tidak diizinkan");
    }
    const body = await response.text();
    res.type(response.headers.get("content-type") || "text/plain").send(body);
  } catch (err) {
    res.status(500).send("Gagal mengambil URL");
  }
});

app.listen(3000, () => console.log("Server aman jalan di http://localhost:3000"));

Kenapa tiap baris ini penting?

• Allowlist hostname memastikan hanya domain yang benar-benar dibutuhkan aplikasi yang bisa diakses, bukan sembarang URL. Ini sesuai rekomendasi resmi OWASP yang menyebut pendekatan allowlist jauh lebih aman dibanding blocklist.

• Validasi skema URL mencegah penyerang memakai skema aneh seperti file://, gopher://, atau dict:// yang bisa dipakai buat baca file lokal atau menyerang layanan lain.

• Cek IP hasil resolve DNS ini krusial buat mencegah teknik DNS rebinding, di mana domain yang lolos allowlist ternyata di-resolve ke IP privat.

• Redirect diset manual, bukan otomatis diikuti karena penyerang bisa memakai domain yang lolos validasi awal, tapi domain itu mengarahkan (redirect) ke alamat internal.

Uji lagi dengan curl yang tadi:

curl "http://localhost:3000/fetch-image?url=http://127.0.0.1:5000/admin/users"

Output yang diharapkan sekarang:

Host tidak ada di daftar yang diizinkan

Kalau respons ini yang muncul, berarti perbaikannya berhasil.

Step 6: Tambahkan Lapisan Pertahanan di Level Jaringan

Validasi di kode itu penting, tapi jangan berhenti di situ saja. Idealnya, terapkan juga pertahanan berlapis di level jaringan:

• Terapkan kebijakan "deny by default" di firewall, jadi server aplikasi cuma boleh keluar ke domain atau IP yang benar-benar dibutuhkan.

• Kalau pakai Kubernetes, pasang NetworkPolicy yang memblokir akses ke endpoint metadata cloud secara default di seluruh cluster.

• Kalau pakai AWS, aktifkan IMDSv2 dan batasi hop limit token metadata supaya request dari luar container susah "melompat" ke endpoint metadata.

• Jangan taruh layanan sensitif seperti dashboard admin atau database tanpa autentikasi di jaringan yang sama dengan server yang menerima input pengguna.

Kenapa lapisan jaringan ini tetap dibutuhkan meski kode sudah divalidasi? Karena validasi di level aplikasi bisa saja punya celah yang belum kamu sadari. Pertahanan berlapis (defense in depth) memastikan satu kesalahan kecil tidak langsung berujung bencana besar, persis seperti yang terjadi di kasus Capital One tadi.

Error Umum dan Cara Mengatasinya (Troubleshooting)

Beberapa masalah yang sering muncul saat praktik atau implementasi perbaikan SSRF:

Error: TypeError: Failed to parse URL Biasanya muncul kalau input URL kosong atau formatnya tidak lengkap, misalnya lupa menulis skema https://. Solusinya, selalu bungkus parsing URL dengan try...catch seperti di Step 5, dan kembalikan pesan error yang jelas ke pengguna.

Aplikasi tetap bisa diakses meski hostname sudah diblokir Ini biasanya terjadi karena validasi hostname dilakukan sebelum redirect diikuti. Pastikan kamu set redirect: "manual" supaya aplikasi tidak otomatis mengikuti redirect ke alamat lain yang belum tervalidasi.

Allowlist lolos tapi ternyata tetap kena SSRF Ini gejala klasik DNS rebinding. Cek apakah kamu melakukan resolve DNS dua kali, sekali untuk validasi dan sekali lagi saat request asli dikirim. Kalau iya, ini celah, karena DNS bisa saja "berubah" di antara dua pengecekan itu. Solusinya, resolve sekali saja lalu gunakan IP hasil resolve itu langsung untuk request.

Permintaan ke domain internal perusahaan sendiri malah keblokir Kalau aplikasi kamu memang butuh akses ke layanan internal tertentu, tambahkan domain itu secara eksplisit ke allowlist, jangan melonggarkan aturan secara umum. Prinsipnya, izinkan berdasarkan kebutuhan spesifik, bukan berdasarkan pengecualian umum.

Curl mengembalikan connection refused Cek dulu apakah kedua server (server utama dan server "admin internal" tadi) sama-sama masih berjalan di terminal masing-masing. Kesalahan ini sering terjadi karena salah satu proses ke-stop tanpa sadar.

Blocklist vs Allowlist vs Segmentasi Jaringan: Mana yang Paling Ampuh?

Ada beberapa pendekatan populer buat mencegah SSRF, dan masing-masing punya kelebihan serta batasannya sendiri. Berikut perbandingannya:

Rekomendasi berdasarkan kebutuhan:

• Kalau aplikasi kamu cuma perlu mengambil data dari segelintir domain tertentu (misalnya integrasi API pihak ketiga yang sudah pasti), pakai allowlist sebagai lini pertama.

• Kalau kamu butuh solusi cepat sambil menyiapkan perbaikan yang lebih menyeluruh, blocklist bisa dipakai sementara, tapi jangan dijadikan solusi permanen karena gampang dilewati.

• Kalau aplikasi kamu berjalan di infrastruktur cloud dengan banyak layanan internal, segmentasi jaringan wajib ada sebagai lapisan tambahan, bukan pengganti validasi di kode.

Kombinasi ketiganya, dengan allowlist sebagai andalan utama dan segmentasi jaringan sebagai jaring pengaman, adalah pendekatan yang paling direkomendasikan banyak praktisi keamanan, termasuk yang tertuang dalam panduan resmi OWASP soal pencegahan SSRF.

SSRF vs Kerentanan Lain: Biar Nggak Ketuker

Supaya makin jelas posisinya, berikut perbedaan singkat SSRF dengan kerentanan lain yang sering disebut bareng-bareng:

• SSRF vs CSRF — SSRF memanfaatkan server sebagai kaki tangan untuk membuat request, sedangkan CSRF memanfaatkan browser korban yang sedang login untuk mengirim request tanpa disadari pemiliknya.

• SSRF vs XXE (XML External Entity) — keduanya bisa berujung pada akses ke sumber daya yang tidak seharusnya, tapi XXE dieksploitasi lewat parsing dokumen XML yang berisi entitas eksternal, dan kadang bisa terjadi bukan cuma di server, tapi juga di aplikasi client.

• SSRF vs Open Redirect — open redirect kadang jadi "batu loncatan" buat membuat SSRF lolos dari filter allowlist, seperti dijelaskan di bagian bypass filter oleh PortSwigger.

Mulai dari Mana Kalau Baru Kenal SSRF?

Kalau Teman-Teman baru mengenal topik ini dan merasa masih perlu pijakan dasar sebelum eksperimen sendiri, berikut urutan belajar yang MUGHU sarankan:

1. Pahami dulu konsep dasar HTTP request dan response, karena semua serangan SSRF berputar di sekitar ini.

2. Pelajari perbedaan alamat IP privat dan publik, termasuk rentang seperti 127.0.0.1, 10.0.0.0/8, dan 169.254.169.254.

3. Coba praktik langsung seperti langkah-langkah di artikel ini, di lingkungan lokal milik sendiri.

4. Pelajari dokumentasi resmi seperti halaman keamanan MDN soal SSRF untuk memperdalam pemahaman teknis.

5. Ikuti program bug bounty dengan ruang lingkup (scope) yang jelas kalau ingin mempraktikkan di sistem nyata, supaya tetap legal dan etis.

Kesalahan yang Sering Terjadi Saat Menangani SSRF

Dari pengalaman MUGHU membantu beberapa tim menambal celah semacam ini, ada beberapa kesalahan yang berulang kali muncul:

• Cuma mengandalkan blocklist string seperti "localhost" atau "127.0.0.1", padahal penyerang bisa pakai representasi lain seperti 2130706433 (bentuk desimal dari 127.0.0.1) atau 017700000001 (bentuk oktal).

• Lupa memvalidasi redirect, jadi domain yang lolos allowlist ternyata mengarahkan ke alamat internal lewat redirect berantai.

• Menganggap aplikasi aman karena responsnya tidak ditampilkan ke pengguna, padahal itu justru ciri khas blind SSRF yang tetap berbahaya.

• Tidak melindungi endpoint metadata cloud, padahal ini target favorit karena hasilnya langsung berupa kredensial.

• Menunda perbaikan karena dianggap "cuma fitur kecil", padahal fitur kecil seperti "preview link" atau "cek status URL" justru sering jadi titik masuk yang tidak terduga.

Perspektif Bisnis: ROI dari Investasi Mencegah SSRF

Dari sudut pandang manajemen dan pengambil keputusan, mencegah SSRF sebaiknya dilihat bukan sebagai biaya tambahan, melainkan sebagai investasi mitigasi risiko yang terukur.

Biaya menerapkan validasi allowlist dan segmentasi jaringan relatif kecil dibanding potensi kerugian akibat kebocoran data. Sebagai gambaran, kasus Capital One berujung pada denda regulator senilai 80 juta dolar AS ditambah 190 juta dolar untuk penyelesaian gugatan class action, belum termasuk kerugian reputasi yang sulit diukur secara langsung.

Baca juga XSS: Apa Itu, Cara Kerja, dan Cara Mencegahnya

Beberapa metrik yang bisa dipakai tim keamanan untuk mengukur efektivitas program pencegahan SSRF:

• Jumlah endpoint yang menerima input URL dari pengguna dan sudah melalui audit keamanan.

• Persentase layanan internal yang sudah dilindungi lapisan segmentasi jaringan.

• Waktu rata-rata untuk mendeteksi dan menambal celah SSRF yang ditemukan lewat pengujian atau bug bounty.

• Status kepatuhan terhadap kebijakan "deny by default" pada firewall aplikasi.

Investasi di sisi pencegahan biasanya jauh lebih murah dibanding biaya respons insiden, pemulihan reputasi, dan kewajiban hukum yang muncul setelah kebocoran data benar-benar terjadi.

Pengalaman MUGHU Nemuin dan Nutup Celah SSRF

MUGHU masih ingat waktu pertama kali menemukan celah SSRF di sebuah fitur "cek status pembayaran" yang menerima URL callback dari sistem pihak ketiga. Awalnya kelihatan sepele, cuma endpoint kecil yang jarang dipakai. Ternyata setelah dicoba, endpoint itu bisa diarahkan buat mengakses dashboard monitoring internal yang tidak pakai autentikasi tambahan karena dianggap "kan cuma bisa diakses dari dalam jaringan."

Kesalahan yang MUGHU pelajari dari situ: jangan pernah menganggap suatu layanan aman hanya karena "letaknya di dalam jaringan internal." Anggapan seperti itu justru yang bikin SSRF jadi berbahaya, karena begitu server tepercaya berhasil "dititipi" request oleh penyerang, batas jaringan itu jadi tidak berarti apa-apa.

Setelah insiden kecil itu, tim MUGHU akhirnya menetapkan aturan baku: setiap fitur baru yang menerima URL dari pengguna wajib lewat proses tinjauan keamanan sebelum rilis, bukan cuma tinjauan fungsional biasa. Perubahan kecil ini, walau kelihatannya menambah proses, ternyata jauh lebih murah dibanding harus menambal insiden setelah kejadian.

Tips Praktis Biar Aplikasi Kamu Aman dari SSRF

• Selalu tanya ke diri sendiri: "Apakah fitur ini benar-benar butuh menerima URL bebas dari pengguna?" Kalau jawabannya tidak, hilangkan saja fleksibilitas itu.

• Pakai allowlist berbasis domain yang benar-benar dibutuhkan, bukan pola regex yang gampang punya celah.

• Jangan pernah mengikuti redirect secara otomatis tanpa validasi ulang tujuan akhirnya.

• Nonaktifkan skema URL yang tidak dibutuhkan seperti file://, gopher://, dan ftp://.

• Aktifkan autentikasi di semua layanan internal, termasuk yang "cuma dipakai internal," seperti Redis, Elasticsearch, atau dashboard monitoring.

• Pantau log request keluar (outbound) dari server aplikasi, terutama yang menuju rentang IP privat atau endpoint metadata cloud.

• Kalau memungkinkan, gunakan IMDSv2 di AWS atau mekanisme setara di penyedia cloud lain untuk melindungi endpoint metadata.

• Jadikan pengujian SSRF bagian rutin dari proses code review, bukan cuma dicek saat audit keamanan tahunan.

Konteks Lokal: SSRF dan Ekosistem Keamanan Siber di Indonesia

Buat Teman-Teman yang berkecimpung di ekosistem pengembangan aplikasi di Indonesia, isu SSRF ini relevan banget, apalagi makin banyak startup dan perusahaan lokal yang memindahkan infrastrukturnya ke layanan cloud seperti AWS, GCP, atau layanan cloud lokal.

Beberapa hal yang perlu diperhatikan dalam konteks lokal:

• Banyak tim pengembang di kota-kota besar seperti Jakarta, Bandung, dan Surabaya yang mulai aktif mengikuti program bug bounty lokal maupun internasional, di mana SSRF sering jadi salah satu temuan yang dihargai cukup tinggi karena dampaknya yang luas.

• Regulasi seperti UU Perlindungan Data Pribadi (UU PDP) membuat kebocoran data akibat celah seperti SSRF berpotensi menimbulkan konsekuensi hukum bagi perusahaan yang beroperasi di Indonesia, bukan cuma kerugian reputasi.

• Komunitas keamanan siber lokal, termasuk forum-forum diskusi developer dan komunitas cybersecurity di berbagai kampus, makin sering membahas topik ini, jadi ini saat yang tepat buat tim internal perusahaan mulai membangun kebiasaan meninjau keamanan aplikasi secara berkala, bukan cuma menunggu insiden terjadi.

Kapan Sebaiknya Pakai Pendekatan Mana? Rekomendasi Berdasarkan Skenario

Supaya lebih gampang diambil keputusan, berikut rekomendasi ringkas berdasarkan skenario yang biasa ditemui:

• Aplikasi kecil dengan sedikit integrasi eksternal → cukup pakai allowlist domain sederhana di level kode, tanpa perlu infrastruktur tambahan yang rumit.

• Aplikasi enterprise dengan banyak microservices → kombinasikan allowlist di kode dengan segmentasi jaringan dan kebijakan firewall "deny by default."

• Aplikasi yang berjalan penuh di cloud dengan IAM role → prioritaskan perlindungan endpoint metadata lewat IMDSv2 atau mekanisme setara, karena ini target paling sering dieksploitasi dalam skenario nyata.

• Aplikasi yang menerima data dari format XML atau dokumen pihak ketiga → tinjau juga kemungkinan SSRF lewat jalur XXE, bukan cuma lewat parameter URL biasa.

• Tim dengan sumber daya keamanan terbatas → mulai dari langkah paling murah dulu, yaitu validasi allowlist di kode, baru bertahap menambahkan lapisan jaringan.

Checklist Audit SSRF yang Bisa Langsung Kamu Pakai

Sebelum lanjut ke bagian yang lebih teknis, MUGHU mau kasih satu checklist ringkas yang bisa langsung Teman-Teman tempel di dokumen internal tim. Checklist ini disusun dari pengalaman menambal beberapa celah serupa, jadi sifatnya praktis, bukan teori di atas kertas.

• Daftar semua endpoint yang menerima input berupa URL, baik lewat query parameter, body request, header, maupun file konfigurasi (misalnya webhook URL yang disimpan di database).

• Untuk tiap endpoint itu, tentukan apakah benar-benar butuh menerima URL bebas dari pengguna, atau sebenarnya cukup dari daftar domain terbatas.

• Pastikan validasi skema URL sudah diterapkan, minimal hanya mengizinkan https:// dan menolak file://, gopher://, dict://, serta ftp://.

• Cek apakah redirect diikuti otomatis atau tidak. Kalau iya, ubah jadi manual dan validasi ulang tujuan akhirnya.

• Pastikan resolve DNS dilakukan sekali saja, lalu IP hasil resolve itu yang dipakai untuk request asli, bukan resolve dua kali yang rawan DNS rebinding.

• Cek apakah endpoint metadata cloud (169.254.169.254 atau setara di GCP dan Azure) bisa diakses dari server aplikasi. Kalau bisa, segera terapkan IMDSv2 atau mekanisme setara.

• Tinjau log outbound request dari server aplikasi selama seminggu terakhir. Cari pola request ke IP privat atau ke domain yang nggak lazim.

• Pastikan layanan internal seperti Redis, Elasticsearch, atau dashboard monitoring tetap punya autentikasi meski "cuma bisa diakses dari jaringan internal."

• Masukkan pengujian SSRF ke checklist code review, bukan cuma jadi bagian dari audit keamanan tahunan.

Checklist semacam ini kelihatannya sepele, tapi justru yang paling sering kelewat karena tim biasanya fokus ke fitur baru dan lupa meninjau ulang endpoint lama yang sudah jalan bertahun-tahun. MUGHU pernah lihat sendiri, endpoint yang dibikin lima tahun lalu buat "generate thumbnail dari URL" ternyata masih aktif dan nggak pernah disentuh sejak awal, padahal validasinya jauh dari kata memadai.

Kalau Aplikasi Kamu Pakai Python, PHP, atau Java: Prinsipnya Sama, Implementasinya Beda

Contoh kode di bagian awal artikel ini pakai Node.js, tapi prinsip pencegahan SSRF sebenarnya universal. Yang beda cuma cara implementasinya di tiap bahasa. Berikut gambaran singkatnya biar Teman-Teman yang kerja dengan stack lain tetap bisa mengikuti.

Python (Flask + requests)

Di ekosistem Python, library requests sering dipakai buat fitur fetch URL. Masalahnya, requests secara default juga mengikuti redirect dan nggak peduli apakah tujuan akhirnya IP privat atau bukan. Berikut contoh implementasi yang sudah divalidasi:

import ipaddress
import socket
from urllib.parse import urlparse
import requests
from flask import Flask, request, abort

app = Flask(__name__)
ALLOWED_HOSTS = {"images.tokokita.com", "cdn.tokokita.com"}

def is_private_ip(ip):
    try:
        addr = ipaddress.ip_address(ip)
        return addr.is_private or addr.is_link_local or addr.is_loopback
    except ValueError:
        return True

@app.route("/fetch-image")
def fetch_image():
    target = request.args.get("url", "")
    parsed = urlparse(target)

    if parsed.scheme != "https":
        abort(400, "Skema URL tidak diizinkan")

    if parsed.hostname not in ALLOWED_HOSTS:
        abort(400, "Host tidak ada di daftar yang diizinkan")

    resolved_ip = socket.gethostbyname(parsed.hostname)
    if is_private_ip(resolved_ip):
        abort(400, "Alamat tujuan tidak diizinkan")

    resp = requests.get(target, allow_redirects=False, timeout=5)
    if resp.is_redirect:
        abort(400, "Redirect tidak diizinkan")

    return resp.content, 200, {"Content-Type": resp.headers.get("content-type", "text/plain")}

Logikanya persis sama dengan versi Node.js tadi: validasi skema, cocokkan dengan allowlist, resolve DNS lalu cek apakah IP-nya privat, dan matikan auto-redirect. Bedanya cuma sintaks dan nama fungsi bawaan tiap bahasa.

PHP (cURL)

Di PHP, fitur semacam ini biasanya dibikin pakai curl atau file_get_contents. Kalau pakai file_get_contents, risikonya lebih besar karena fungsi ini juga bisa membaca skema file:// dan phar:// tanpa validasi tambahan. Jadi, sebaiknya pakai curl dengan opsi yang dibatasi:

<?php
$allowedHosts = ["images.tokokita.com", "cdn.tokokita.com"];
$target = $_GET['url'] ?? '';
$parsed = parse_url($target);

if (!$parsed || ($parsed['scheme'] ?? '') !== 'https') {
    http_response_code(400);
    exit('Skema URL tidak diizinkan');
}

if (!in_array($parsed['host'] ?? '', $allowedHosts, true)) {
    http_response_code(400);
    exit('Host tidak ada di daftar yang diizinkan');
}

$ip = gethostbyname($parsed['host']);
if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) === false) {
    http_response_code(400);
    exit('Alamat tujuan tidak diizinkan');
}

$ch = curl_init($target);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_PROTOCOLS, CURLPROTO_HTTPS);
$response = curl_exec($ch);
curl_close($ch);

echo $response;

Fungsi filter_var dengan flag FILTER_FLAG_NO_PRIV_RANGE dan FILTER_FLAG_NO_RES_RANGE ini sebenarnya fitur bawaan PHP yang jarang diketahui banyak developer, padahal berguna banget buat mendeteksi IP privat dan reserved tanpa perlu bikin regex sendiri.

Java (Spring Boot)

Di ekosistem Java, biasanya tim pakai RestTemplate atau WebClient. Prinsip yang sama tetap berlaku, cuma perlu tambahan RequestConfig untuk mematikan redirect otomatis, dan validasi host dilakukan sebelum request dibuat lewat interceptor atau service layer terpisah. Beberapa tim enterprise malah memilih pakai library pihak ketiga seperti ssrf-req-filter di Node.js atau menulis URLConnection custom di Java yang secara eksplisit menolak resolve ke rentang IP privat.

Poin pentingnya, apa pun bahasa pemrogramannya, empat pilar validasi ini harus selalu ada: validasi skema, validasi host lewat allowlist, validasi IP hasil resolve DNS, dan kontrol redirect. Kalau salah satu pilar ini hilang, celahnya tetap terbuka meski tiga lainnya sudah rapi.

Tools yang Bisa Bantu Kamu Nemuin dan Ngetes SSRF

Selain menulis validasi manual, ada beberapa tools yang biasa dipakai tim keamanan buat mendeteksi SSRF, baik yang basic maupun blind. MUGHU coba rangkum yang paling sering dipakai di lapangan, lengkap dengan catatan kelebihan dan keterbatasannya.

Kalau tim kamu baru mulai membangun proses pengujian SSRF secara rutin, kombinasi OWASP ZAP untuk pemindaian awal dan Interactsh untuk verifikasi blind SSRF sudah cukup jadi titik awal yang solid tanpa perlu biaya lisensi. Setelah proses ini matang, baru pertimbangkan Burp Suite Professional untuk kebutuhan pengujian yang lebih mendalam, terutama kalau tim keamanan kamu sudah menangani banyak aplikasi sekaligus.

Satu catatan penting, tools ini membantu menemukan celah, tapi tetap kamu yang harus menambalnya. MUGHU pernah lihat tim yang bangga banget karena laporan pemindaian mereka "bersih," padahal itu cuma karena tool-nya nggak dikonfigurasi buat mengecek endpoint yang menerima URL lewat body JSON, bukan cuma query parameter.

Studi Kasus Kedua: SSRF di Balik Insiden ProxyLogon Microsoft Exchange

Selain kasus Capital One yang sudah dibahas di awal, ada satu studi kasus lain yang juga penting dipahami karena skalanya global dan melibatkan software yang dipakai jutaan perusahaan: insiden ProxyLogon pada Microsoft Exchange Server tahun 2021.

Latar belakang: Microsoft Exchange Server adalah platform email dan kolaborasi yang dipakai luas oleh perusahaan besar maupun kecil di seluruh dunia, termasuk banyak instansi di Indonesia.

Masalahnya: Peneliti menemukan celah SSRF yang tercatat sebagai CVE-2021-26855, di mana penyerang yang bahkan belum terautentikasi bisa mengirim request HTTP yang dipalsukan seolah-olah berasal dari server Exchange itu sendiri ke komponen internal lain di server yang sama.

Pendekatan penyerang: Kelompok yang diidentifikasi Microsoft sebagai HAFNIUM memanfaatkan celah SSRF ini sebagai titik masuk awal, lalu merangkainya dengan beberapa kerentanan lain, termasuk celah yang memungkinkan penulisan file secara sembarangan di server. Rangkaian ini akhirnya bisa dipakai buat menanam web shell dan mendapatkan kendali penuh atas server Exchange korban.

Hasilnya: Ribuan organisasi di berbagai negara terdampak dalam hitungan hari setelah eksploitasi mulai marak, mendorong Microsoft merilis patch darurat di luar jadwal rutin Patch Tuesday mereka. Detail teknis dan mitigasi resminya bisa Teman-Teman baca langsung di blog resmi Microsoft Security Response Center soal insiden ini.

Pelajaran kuncinya: Kasus ini menegaskan satu hal yang sudah disinggung sebelumnya di artikel ini, bahwa SSRF jarang berdiri sendiri. Dia biasanya jadi titik masuk awal dalam rangkaian serangan yang lebih besar. Software sekelas Microsoft Exchange saja, yang sudah melalui proses pengembangan dan pengujian keamanan yang matang, tetap bisa kebobolan lewat celah SSRF. Ini jadi pengingat bahwa pengujian SSRF nggak boleh dianggap "sudah selesai" hanya karena aplikasi sudah lama berjalan tanpa insiden.

Bedanya dengan kasus Capital One, di ProxyLogon celah SSRF dipakai buat menyerang komponen internal di server yang sama (SSRF ke localhost pada dasarnya), sedangkan di Capital One celah SSRF dipakai buat menjangkau layanan metadata cloud eksternal. Dua pola ini sama-sama sering ditemukan di lapangan, dan keduanya sama-sama berbahaya.

SSRF vs Kerentanan Cloud-Native Lain: Biar Nggak Salah Prioritas

Di lingkungan cloud, SSRF sering disebut bareng beberapa kerentanan lain yang juga berkaitan dengan infrastruktur. Supaya Teman-Teman nggak bingung membedakan mana yang harus diprioritaskan duluan, berikut perbandingannya:

• SSRF vs Container Escape — SSRF terjadi di level aplikasi yang memanfaatkan server buat mengirim request ke tujuan yang tidak sah, sedangkan container escape terjadi ketika penyerang berhasil keluar dari batas isolasi container dan mengakses host di baliknya. Keduanya bisa saling melengkapi, SSRF kadang jadi jalan masuk awal, container escape jadi eskalasi lanjutannya.

• SSRF vs IAM Misconfiguration — SSRF adalah celah di aplikasi, sedangkan IAM misconfiguration adalah kesalahan di sisi konfigurasi izin akses. Kasus Capital One membuktikan kombinasi keduanya yang bikin dampaknya jadi luar biasa besar, padahal masing-masing kalau berdiri sendiri mungkin dampaknya lebih terbatas.

• SSRF vs Supply Chain Attack — supply chain attack menyusup lewat dependensi atau pihak ketiga yang dipercaya, sedangkan SSRF menyusup lewat fitur aplikasi yang menerima input URL. Keduanya sama-sama memanfaatkan "kepercayaan" sebagai celah utama, cuma dari sisi yang berbeda.

Kenapa perbandingan ini penting? Karena tim keamanan dengan sumber daya terbatas perlu tahu mana yang harus ditangani lebih dulu. Rekomendasi umum dari praktisi adalah menangani SSRF dan IAM misconfiguration secara bersamaan, karena kombinasi keduanyalah yang paling sering muncul di laporan insiden besar seperti yang sudah dibahas di atas.

Menulis Kebijakan Keamanan Internal soal SSRF di Tim Kamu

Kalau Teman-Teman kebetulan bertanggung jawab atas standar keamanan di tim atau perusahaan, berikut kerangka kebijakan sederhana yang bisa diadaptasi:

1. Tentukan definisi "fitur berisiko SSRF" secara eksplisit. Jangan biarkan definisi ini kabur. Tuliskan dengan jelas bahwa fitur yang menerima URL dari pengguna, baik langsung maupun tidak langsung (misalnya lewat webhook, callback, atau import dari file), termasuk kategori ini.

2. Wajibkan tinjauan keamanan sebelum fitur semacam itu dirilis. Sama seperti yang MUGHU ceritakan sebelumnya, aturan ini terdengar menambah proses, tapi jauh lebih murah dibanding menambal insiden setelah kejadian.

3. Standarkan pola validasi di level kode. Sediakan library atau helper function internal yang sudah menerapkan empat pilar validasi (skema, allowlist, resolve DNS, kontrol redirect), supaya tim nggak perlu menulis ulang logika yang sama setiap kali ada fitur baru.

4. Tentukan pemilik untuk allowlist domain. Allowlist yang nggak punya pemilik jelas biasanya lama-lama jadi berantakan, ada domain lama yang nggak dipakai tapi nggak pernah dihapus, atau permintaan penambahan domain baru yang disetujui tanpa peninjauan.

5. Masukkan SSRF ke dalam program bug bounty atau pengujian berkala. Kalau perusahaan kamu punya program bug bounty, pastikan cakupannya mencakup endpoint yang menerima input URL. Kalau belum punya, pengujian berkala minimal setahun sekali oleh pihak ketiga juga sudah cukup membantu.

6. Dokumentasikan setiap temuan dan perbaikannya. Ini penting buat audit di masa depan, dan juga membantu tim baru memahami kenapa suatu validasi ada di kode, bukan cuma "ikut-ikutan pola yang sudah ada."

Kebijakan semacam ini nggak harus rumit atau panjang halamannya. Yang penting jelas, bisa diikuti, dan benar-benar dipraktikkan, bukan cuma dokumen yang disimpan di folder yang jarang dibuka.

Pertanyaan yang Sering Muncul soal SSRF

Apakah SSRF cuma masalah aplikasi berbasis cloud? Tidak. SSRF bisa terjadi di aplikasi mana pun yang menerima URL dari pengguna dan melakukan request atas nama server, baik itu dijalankan di cloud maupun di server on-premise. Cuma memang dampaknya sering terasa lebih besar di cloud karena adanya endpoint metadata yang menyimpan kredensial.

Apakah firewall biasa cukup buat mencegah SSRF? Firewall jaringan membantu, tapi nggak cukup sendirian. Firewall biasanya melindungi dari request yang datang dari luar, sedangkan SSRF memanfaatkan request yang berasal dari dalam jaringan itu sendiri, yaitu dari server aplikasi. Makanya validasi di level kode tetap wajib ada.

Kenapa blocklist string seperti "localhost" gampang dilewati? Karena penyerang punya banyak cara merepresentasikan alamat yang sama. Selain bentuk desimal dan oktal yang sudah disinggung sebelumnya, ada juga trik pakai alamat IPv6 seperti ::1, atau domain yang sengaja di-resolve ke IP privat. Validasi berbasis resolve DNS dan pengecekan rentang IP jauh lebih andal dibanding sekadar mencocokkan string.

Apakah aplikasi mobile juga bisa kena SSRF? SSRF secara definisi menyerang sisi server, jadi aplikasi mobile sendiri nggak langsung kena. Tapi kalau backend yang melayani aplikasi mobile itu punya fitur fetch URL yang nggak divalidasi, backend itulah yang jadi sasaran empuknya, meski request awalnya datang dari aplikasi mobile.

Berapa lama biasanya proses menambal SSRF sampai selesai? Tergantung kompleksitas aplikasi. Untuk aplikasi kecil dengan satu atau dua endpoint berisiko, biasanya bisa selesai dalam hitungan hari. Untuk aplikasi enterprise dengan puluhan microservices, prosesnya bisa memakan waktu berminggu-minggu karena butuh koordinasi lintas tim, terutama kalau segmentasi jaringan juga harus disesuaikan.

Apakah WAF (Web Application Firewall) bisa mencegah semua jenis SSRF? Nggak sepenuhnya. WAF bisa membantu memblokir pola serangan yang sudah dikenal, tapi seperti yang terjadi di kasus Capital One, WAF itu sendiri bisa jadi korban SSRF kalau konfigurasinya keliru. WAF sebaiknya dianggap sebagai lapisan tambahan, bukan solusi tunggal.

Apakah SSRF termasuk kerentanan yang gampang dideteksi lewat automated scanning? Untuk basic SSRF, iya, relatif gampang dideteksi. Tapi untuk blind SSRF, automated scanning biasa sering kelewat kalau nggak dikonfigurasi khusus buat memanfaatkan layanan out-of-band seperti Interactsh atau Burp Collaborator yang sudah dibahas di bagian tools tadi.

Referensi dan Bacaan Lanjutan yang Kredibel

Buat Teman-Teman yang mau memperdalam topik ini lebih jauh, berikut beberapa sumber yang MUGHU rekomendasikan karena kredibel dan sering dijadikan rujukan komunitas keamanan global:

• OWASP Cheat Sheet Series khusus pencegahan SSRF, berisi panduan teknis yang lebih rinci soal implementasi allowlist dan penanganan DNS rebinding.

• Dokumentasi resmi masing-masing penyedia cloud soal keamanan endpoint metadata, termasuk panduan IMDSv2 dari AWS dan pengaturan setara di GCP maupun Azure.

• Laporan-laporan bug bounty publik di platform seperti HackerOne dan Bugcrowd, yang sering memuat studi kasus SSRF nyata lengkap dengan detail teknisnya, bagus buat latihan membaca pola pikir penyerang.

• Modul pembelajaran interaktif dari PortSwigger yang sudah disinggung sebelumnya, cocok buat latihan langsung di lingkungan yang aman dan legal.

Menguasai SSRF bukan soal menghafal satu daftar validasi lalu selesai. Ancaman ini terus berkembang mengikuti perubahan arsitektur aplikasi, dari monolitik ke microservices, dari server fisik ke cloud, dari HTTP biasa ke gRPC dan protokol lain yang juga rawan disalahgunakan dengan pola serupa. Kebiasaan meninjau ulang fitur yang menerima input URL secara berkala, itulah yang sebenarnya jadi pertahanan paling tahan lama, jauh lebih tahan lama dibanding validasi kode yang sekali ditulis lalu nggak pernah disentuh lagi.

SSRF di Lingkungan Serverless dan Container: Ada PR Baru yang Muncul

Banyak tim yang mikir, "kalau sudah pindah ke serverless atau container, urusan SSRF otomatis kelar." Nyatanya nggak sesederhana itu. Memang ada beberapa hal yang jadi lebih aman secara default, tapi muncul juga tantangan baru yang jarang dibahas.

Di AWS Lambda misalnya, setiap fungsi biasanya punya execution role sendiri-sendiri, jadi blast radius-nya lebih kecil dibanding satu instance EC2 raksasa yang dipakai bareng-bareng banyak layanan seperti kasus Capital One. Tapi justru di sinilah jebakannya: karena role-nya kelihatan "kecil dan spesifik," banyak tim jadi kurang hati-hati soal izin yang dikasih. Ujung-ujungnya tetap sama, kalau fungsi itu kena SSRF dan role-nya kebetulan punya akses ke S3 atau Secrets Manager, penyerang tetap bisa panen data.

Di dunia container dan Kubernetes, tantangannya lebih ke arah komunikasi antar service yang saking gampangnya, kadang nggak ada validasi sama sekali karena dianggap "kan sesama internal." Padahal, begitu satu container kena SSRF, dia bisa jadi batu loncatan buat menjangkau service lain di cluster yang sama, apalagi kalau NetworkPolicy belum diterapkan dengan benar. Kalau Teman-Teman penasaran soal cara mengatur kebijakan jaringan semacam ini, dokumentasi resmi Kubernetes soal NetworkPolicy lumayan lengkap buat jadi rujukan awal.

Beberapa tim yang sudah matang biasanya menambahkan lapisan lagi lewat service mesh seperti Istio atau Linkerd, yang bisa memaksa komunikasi antar service pakai mTLS dan kebijakan otorisasi yang eksplisit. Jadi meski satu service kena SSRF, dia tetap nggak bisa asal ngobrol sama service lain kalau memang nggak diizinkan secara eksplisit. Ini bukan solusi ajaib yang bikin SSRF hilang total, tapi lumayan mempersempit ruang gerak penyerang kalau memang celahnya sudah kadung ada.

Satu hal lagi yang sering kelewat di lingkungan serverless: cold start dan timeout yang pendek kadang bikin tim malas nambahin validasi ekstra kayak resolve DNS dua kali atau pengecekan IP privat, karena takut nambah latensi. Padahal validasi semacam itu biasanya cuma nambah beberapa milidetik saja. MUGHU pernah ngobrol sama satu tim yang awalnya keberatan soal ini, tapi setelah diukur beneran, tambahan latensinya nggak sampai memengaruhi pengalaman pengguna. Jadi alasan "nanti lambat" itu kadang cuma asumsi, bukan fakta yang benar-benar diukur.

Kenapa Satu Kali Tambal Aja Nggak Cukup

Ada satu pola yang MUGHU perhatikan berulang kali di berbagai tim: begitu celah SSRF ditemukan dan ditambal, semua orang lega, lanjut kerja seperti biasa, terus lupa lagi sampai insiden berikutnya muncul. Padahal aplikasi itu hidup, terus berubah, ada fitur baru, ada integrasi baru, ada dependency yang diupdate. Validasi yang dulu ketat, bisa jadi longgar lagi tanpa disadari, misalnya gara-gara ada library baru yang diam-diam mengikuti redirect otomatis padahal sebelumnya sudah dimatikan.

Makanya, selain checklist dan kebijakan yang sudah dibahas sebelumnya, penting juga bikin kebiasaan kecil yang jalan terus-menerus. Beberapa contoh yang MUGHU lihat efektif di lapangan:

• Tambahkan pengujian SSRF otomatis ke pipeline CI/CD, jadi setiap kali ada perubahan kode di endpoint yang menerima URL, ada pemeriksaan otomatis yang jalan duluan sebelum kode itu naik ke produksi.

• Bikin sesi review singkat tiap kali ada integrasi baru dengan pihak ketiga, terutama yang melibatkan webhook atau callback URL, karena ini area yang paling sering luput dari radar tim keamanan.

• Rotasi tanggung jawab peninjauan allowlist domain, jangan cuma dipegang satu orang terus-menerus, biar ada "mata kedua" yang rutin ngecek apakah masih relevan.

• Simulasikan skenario SSRF secara berkala lewat latihan internal, mirip tabletop exercise, biar tim yang menangani insiden beneran paham langkah-langkah yang harus diambil kalau kejadian sungguhan muncul.

Kebiasaan-kebiasaan kecil ini kelihatannya remeh, tapi justru itu yang bikin pertahanan tetap relevan seiring waktu. Perusahaan sekelas Microsoft yang punya tim keamanan raksasa saja masih bisa kebobolan lewat ProxyLogon seperti yang sudah dibahas tadi. Jadi rasanya wajar kalau tim yang lebih kecil juga menganggap SSRF sebagai risiko yang butuh perhatian terus-menerus, bukan proyek yang selesai begitu satu sprint perbaikan kelar.

Buat Teman-Teman yang mau menstandarkan proses ini di skala organisasi, kerangka kerja seperti NIST Secure Software Development Framework bisa jadi acuan tambahan, khususnya di bagian yang membahas peninjauan keamanan sepanjang siklus pengembangan, bukan cuma di ujung sebelum rilis. Menggabungkan kerangka semacam ini dengan kebiasaan teknis yang sudah dibahas di artikel ini, allowlist, validasi redirect, segmentasi jaringan, dan pengujian rutin, biasanya jadi kombinasi yang paling realistis buat dijalankan tim dengan sumber daya terbatas sekalipun.

Kesimpulan

Kalau ditarik benang merahnya, SSRF sebenarnya bukan soal satu baris kode yang lupa divalidasi, tapi soal kebiasaan yang perlahan mengendur seiring waktu. Validasi IP privat, resolve DNS dua kali, allowlist domain, sampai pengujian otomatis di CI/CD, semuanya kelihatan sepele satu-satu, tapi begitu digabung jadi rutinitas, itulah yang bikin celah seperti ProxyLogon jadi jauh lebih sulit terulang. MUGHU sengaja menekankan poin latensi di awal karena ini alasan paling umum tim menunda validasi, padahal begitu diukur langsung, dampaknya nyaris tidak terasa dibanding risiko yang dicegah.

Pelajaran paling penting dari kasus Microsoft bukan berarti tim keamanan besar itu ceroboh, melainkan bukti bahwa SSRF adalah risiko yang terus berevolusi mengikuti perubahan aplikasi. Library baru yang diam-diam mengikuti redirect, integrasi pihak ketiga yang terburu-buru, atau allowlist yang tidak pernah ditinjau ulang, semuanya bisa membuka celah yang sama meski sudah pernah ditambal. Di sinilah kebiasaan kecil seperti rotasi peninjauan allowlist dan simulasi insiden berkala jadi pembeda antara tim yang benar-benar tangguh dan tim yang cuma merasa aman.

Buat Teman-Teman yang ingin membawa ini ke level yang lebih terstruktur, memadukan praktik teknis di atas dengan kerangka kerja seperti NIST Secure Software Development Framework bisa membantu menjadikan peninjauan keamanan sebagai bagian rutin dari siklus pengembangan, bukan langkah darurat di menit terakhir. Tidak perlu menerapkan semuanya sekaligus. Mulai saja dari satu kebiasaan yang paling mudah diterapkan minggu ini, entah itu menambahkan validasi IP privat di endpoint yang paling sering diakses publik atau menjadwalkan review pertama untuk allowlist domain, karena pertahanan terhadap SSRF yang paling kuat selalu dimulai dari langkah kecil yang benar-benar dijalankan, bukan dari rencana besar yang tidak pernah dieksekusi.

Referensi

OWASP. (2026). Server-Side Request Forgery.

PortSwigger. (2026). Server-Side Request Forgery (SSRF).

GeeksforGeeks. (2026). Server-Side Request Forgery (SSRF) in Depth.

MDN Web Docs. (2026). Server-Side Request Forgery (SSRF).

OWASP. (2026). A10:2021 – Server-Side Request Forgery (SSRF).

Snyk Learn. (2026). Server-Side Request Forgery (SSRF).

Wikipedia. (2026). Server-Side Request Forgery.

CWE. (2026). CWE-918: Server-Side Request Forgery (SSRF).

Wiz. (2026). Server-Side Request Forgery: What It Is and How to Fix It.

Imperva. (2026). Server-Side Request Forgery (SSRF).