--- title: "SSRF, Celah yang Membuat Server Menyerang Dirinya Sendiri" description: "SSRF membuat server mengirim permintaan atas perintah penyerang, termasuk ke layanan internal dan metadata cloud. Pahami cara kerja dan pencegahannya." url: "https://nivelva.com/insight/ssrf-celah-membuat-server-menyerang-sendiri" category: "Keamanan/Cyber Security" tags: ["ssrf","owasp","keamanan aplikasi","metadata cloud","api"] author: "Lucas Tan" published: "2026-11-11T13:00:00+07:00" updated: "2026-11-11T13:00:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # SSRF, Celah yang Membuat Server Menyerang Dirinya Sendiri > **Jawaban singkat:** SSRF terjadi saat aplikasi mau mengambil URL apa pun dari pengguna. Penyerang memakainya untuk menyuruh server mengakses layanan internal atau metadata cloud berisi kredensial. Cegah dengan allowlist tujuan dan pembatasan jaringan keluar. SSRF (Server-Side Request Forgery) adalah celah yang membuat server mengirim permintaan ke alamat pilihan penyerang. Karena permintaan itu datang dari dalam, server bisa menjangkau tempat yang tidak bisa dijangkau penyerang secara langsung: layanan internal, panel admin yang hanya mendengarkan di `localhost`, database tanpa password di jaringan privat, sampai endpoint metadata cloud yang menyimpan kredensial. Kenapa ini penting? Banyak aplikasi modern punya fitur yang "mengambil sesuatu dari URL": pratinjau tautan, impor gambar dari alamat web, webhook, pembuat PDF dari halaman, atau integrasi API. Setiap fitur seperti itu adalah pintu SSRF bila tujuannya tidak dibatasi. ## Bagaimana SSRF bekerja? Bayangkan fitur "unggah foto profil dari URL". Pengguna mengisi alamat gambar, lalu server mengunduhnya. Normalnya isinya `https://contoh.com/foto.jpg`. Penyerang mengisi alamat lain: - `http://127.0.0.1:8080/admin` untuk membuka panel admin yang hanya bisa diakses dari server itu sendiri. - `http://10.0.0.5:6379/` untuk mencolek Redis di jaringan internal. - `http://169.254.169.254/` untuk mengakses layanan metadata instance di banyak penyedia cloud. Server patuh saja, karena kodenya memang hanya menerima URL lalu mengambilnya. Kalau respons ditampilkan kembali ke pengguna, penyerang bisa membaca hasilnya. Ini disebut SSRF biasa. Kalau respons tidak ditampilkan, penyerang masih bisa menebak dari waktu respons atau pesan error. Ini disebut blind SSRF, lebih lambat dieksploitasi tapi tetap berbahaya. ## Kenapa endpoint metadata cloud jadi sasaran favorit? Di banyak platform cloud, mesin virtual bisa bertanya ke alamat khusus `169.254.169.254` untuk mengetahui informasi tentang dirinya. Pada konfigurasi tertentu, jawabannya termasuk kredensial sementara untuk peran (role) yang terpasang di mesin itu. Artinya, satu celah SSRF di aplikasi web bisa berujung pada pencurian kunci akses cloud. Dengan kunci itu, penyerang bisa membaca bucket penyimpanan atau layanan lain sesuai izin role tersebut. Penyedia cloud sudah menambah perlindungan. Di AWS misalnya, IMDSv2 mewajibkan permintaan token lewat metode `PUT` dengan header khusus sebelum metadata bisa dibaca, sehingga permintaan `GET` sederhana hasil SSRF tidak cukup. AWS menganjurkan mewajibkan IMDSv2 pada instance. Kalau kamu memakai cloud, periksa apakah pengaturan serupa sudah aktif. ## Di mana SSRF dalam daftar OWASP? Pada OWASP Top 10 2021, SSRF punya kategori sendiri (A10). Pada OWASP Top 10 2025, SSRF (CWE-918) digabung ke dalam kategori A01 Broken Access Control. Penggabungan ini tidak berarti risikonya mengecil. Intinya tetap sama: server diberi akses ke sumber daya yang seharusnya tidak boleh dijangkau atas permintaan pengguna. Kalau ingin gambaran utuh seluruh kategori, baca [OWASP Top 10 untuk pemilik website](https://nivelva.com/insight/owasp-top-10-dijelaskan-pemilik-website). Celah lain di kategori yang sama, yaitu [IDOR](https://nivelva.com/insight/idor-celah-akses-data-orang-lain-hanya-ganti-angka), juga sering ditemukan di aplikasi bisnis. ## Fitur aplikasi yang rawan SSRF | Fitur | Contoh | Risiko bila tidak dibatasi | |:--|:--|:--| | Ambil gambar dari URL | Foto profil, impor katalog produk | Server mengakses alamat internal | | Pratinjau tautan | Chat, komentar, CMS | Penyerang memetakan jaringan privat | | Webhook keluar | Notifikasi ke URL pelanggan | Webhook diarahkan ke layanan lokal | | Konversi HTML ke PDF | Faktur, laporan | Renderer memuat sumber internal | | Impor file XML | Integrasi data | XXE dapat berujung SSRF | | Proxy atau fetch API | Aplikasi yang meneruskan permintaan | Akses ke metadata cloud dan admin lokal | ## Bagaimana cara mencegah SSRF? Pencegahan yang efektif berlapis, karena satu lapis saja mudah diakali. - **Pakai daftar izin (allowlist), bukan daftar larangan.** Kalau fitur hanya perlu mengambil dari domain mitra tertentu, izinkan domain itu saja. Daftar larangan seperti "tolak 127.0.0.1" gampang dilewati dengan penulisan alamat lain, misalnya bentuk desimal, IPv6, atau nama domain yang mengarah ke IP lokal. - **Validasi setelah resolusi DNS.** Cek alamat IP hasil resolusi, bukan hanya teks URL. Tolak rentang privat, loopback, link-local (`169.254.0.0/16`), dan alamat khusus lainnya. Pastikan koneksi benar-benar dibuat ke IP yang sudah divalidasi, agar tidak tertipu DNS rebinding. - **Matikan pengalihan otomatis** (redirect) di klien HTTP, atau validasi ulang setiap tujuan pengalihan. - **Batasi skema.** Izinkan hanya `https` (atau `http` bila perlu). Tolak `file://`, `gopher://`, `ftp://`, dan skema lain yang tidak dibutuhkan. - **Jangan kembalikan respons mentah** ke pengguna. Ambil data yang diperlukan saja, misalnya pastikan hasilnya memang gambar. - **Batasi jaringan keluar di level server.** Aturan firewall yang mencegah server aplikasi menghubungi jaringan internal atau endpoint metadata adalah lapisan terakhir yang sangat membantu. > **Kredensial di server juga ikut terancam:** > > SSRF sering dikombinasikan dengan pencarian file konfigurasi atau kunci API yang tersimpan sembarangan. Simpan rahasia dengan benar dan batasi izinnya. Panduan [mencegah bocornya file .env dan API key](https://nivelva.com/insight/mencegah-bocor-file-env) membahas cara praktisnya. ## Apakah WAF cukup untuk menahan SSRF? WAF bisa menghentikan pola serangan yang umum, misalnya parameter berisi `169.254.169.254` atau `localhost`. Tapi WAF melihat permintaan dari luar, bukan logika aplikasimu. Penyerang yang memakai pengodean alamat yang tidak lazim atau domain miliknya sendiri yang mengarah ke IP internal masih bisa lolos. Jadi WAF berguna sebagai lapisan tambahan, sementara perbaikan utama tetap di kode dan konfigurasi jaringan. Penjelasan tentang kapan [WAF](https://nivelva.com/insight/apa-itu-waf) layak dipakai bisa jadi bahan pertimbangan. ## Cara menguji apakah aplikasimu rawan Kumpulkan dulu semua fitur yang menerima URL atau alamat dari pengguna, termasuk yang tersembunyi di API. Untuk setiap fitur, coba masukkan alamat ke server uji yang kamu kendalikan dan lihat apakah server aplikasi menghubunginya. Jika ya, lanjutkan dengan mencoba alamat lokal di lingkungan uji, bukan di produksi. Pengujian seperti ini sebaiknya dilakukan oleh orang yang paham dan dengan izin tertulis bila aplikasinya milik pihak lain. Hasilnya dicatat sebagai temuan, lalu diperbaiki di kode. ## Pertanyaan yang sering diajukan ### Apa beda SSRF dan CSRF? CSRF menipu browser pengguna agar mengirim permintaan ke situs tempat ia sudah login. SSRF menipu server agar mengirim permintaan ke alamat pilihan penyerang. Korbannya berbeda: browser pada CSRF, server pada SSRF. ### Apakah website WordPress biasa bisa terkena SSRF? Bisa, bila ada plugin atau tema yang mengambil URL dari masukan pengguna tanpa validasi. Karena itu plugin perlu diperbarui rutin dan plugin yang tidak dipakai sebaiknya dihapus. ### Apakah VPS tanpa layanan cloud metadata aman dari SSRF? Risiko pencurian kredensial cloud memang tidak ada, tapi SSRF tetap bisa dipakai untuk mengakses layanan lokal seperti panel admin, Redis, atau database yang hanya mendengarkan di localhost. ## Sumber - - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/ssrf-celah-membuat-server-menyerang-sendiri Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com