---
title: "Path Traversal, Celah untuk Membaca File Rahasia Server"
description: "Path traversal membuat penyerang bisa membaca file di luar folder semestinya, seperti .env. Kenali penyebab, tanda, dan cara menutupnya."
url: "https://nivelva.com/insight/path-traversal-celah-membaca-file-rahasia-server"
category: "Keamanan/Cyber Security"
tags: ["path traversal","keamanan website","owasp","cwe-22","php"]
author: "Lucas Tan"
published: "2026-11-11T13:16:00+07:00"
updated: "2026-11-11T13:16:00+07:00"
language: "id"
publisher: "Nivelva (https://nivelva.com)"
---

# Path Traversal, Celah untuk Membaca File Rahasia Server

> **Jawaban singkat:** Path traversal terjadi saat aplikasi menyusun lokasi file dari input pengguna tanpa batasan, sehingga penyerang bisa keluar dari folder yang diizinkan dan membaca file sensitif seperti .env. Penangkalnya: hindari nama file dari input, normalkan path, dan batasi hak akses.

Sebuah toko online punya tombol "unduh invoice". Saat diklik, alamatnya berubah menjadi sesuatu seperti `download.php?file=invoice-1024.pdf`. Sekilas wajar. Masalahnya, aplikasi itu langsung mengambil nilai `file` lalu membuka file dengan nama tersebut dari folder invoice, tanpa memeriksa apa isinya.

Di situlah path traversal muncul. Dengan memanipulasi nilai parameter itu, penyerang bisa membuat aplikasi "naik" keluar dari folder invoice dan membaca file lain di server: file `.env` berisi password database, file konfigurasi, kunci API, sampai berkas sistem. Celah ini juga dikenal dengan nama directory traversal, dan tercatat di daftar kelemahan MITRE sebagai CWE-22.

## Kenapa celah sederhana ini berbahaya?

Dampak path traversal bergantung pada file apa yang bisa dijangkau. Pada kasus paling umum, penyerang membaca file. Itu saja sudah cukup parah, karena satu file `.env` atau `wp-config.php` bisa berisi kredensial database, kunci rahasia aplikasi, dan token layanan pihak ketiga. Dengan kredensial itu, serangan bisa berlanjut ke database dan layanan lain.

Pada kasus yang lebih buruk, celah yang sama terjadi di fitur yang **menulis** file, misalnya fitur upload atau ekstraksi arsip ZIP. Penyerang lalu bisa menimpa file di luar folder yang semestinya, termasuk menaruh skrip yang kemudian dijalankan server. Di titik ini, kebocoran data berubah menjadi pengambilalihan server.

Celah ini bukan hanya milik aplikasi buatan sendiri. Banyak CVE di perangkat jaringan, plugin CMS, dan server aplikasi berupa path traversal. Dalam OWASP Top 10 2021, CWE-22 dikelompokkan ke kategori A01 Broken Access Control, kategori yang menempati peringkat pertama. Penjelasan kategori lainnya ada di [OWASP Top 10 untuk pemilik website](https://nivelva.com/insight/owasp-top-10-dijelaskan-pemilik-website).

## Dari mana celah ini biasanya muncul

Polanya hampir selalu sama: aplikasi menyusun path file dengan menggabungkan folder dasar dan sesuatu yang dikendalikan pengguna. Beberapa tempat yang sering bermasalah:

- Fitur unduh atau pratinjau file berdasarkan nama di URL.
- Pemilih template, bahasa, atau tema yang memuat file berdasarkan parameter, misalnya `?lang=id`.
- Fitur upload yang memakai nama file asli dari pengguna tanpa diubah.
- Ekstraksi file ZIP atau TAR yang tidak memeriksa path di dalam arsip (sering disebut zip slip).
- Konfigurasi web server yang keliru, misalnya direktif `alias` di Nginx yang lokasinya tidak diakhiri garis miring sementara path tujuannya diakhiri garis miring.

Penyaringan sederhana sering gagal. Pengembang kerap hanya menghapus karakter tertentu, padahal penyerang bisa memakai penulisan alternatif seperti encoding URL atau garis miring terbalik di server Windows. Karena itu, pertahanan yang baik tidak bergantung pada daftar karakter terlarang.

Untuk menemukannya di aplikasimu sendiri, mulailah dari kode, bukan dari serangan. Cari fungsi yang membuka, membaca, atau menyertakan file, seperti `include`, `require`, `fopen`, `file_get_contents`, dan `readfile` di PHP, lalu telusuri apakah ada bagian path yang berasal dari parameter URL, formulir, cookie, atau header. Setiap temuan seperti itu layak ditinjau ulang, meskipun saat ini terlihat aman.

## Cara menutup celahnya

Tabel berikut merangkum lapisan pertahanan dari yang paling efektif:

| Lapisan | Yang dilakukan | Catatan |
|:--|:--|:--|
| Jangan pakai nama file dari input | Pakai ID dan cari nama file aslinya di database | Paling kuat, input tidak pernah menjadi path |
| Daftar yang diizinkan (allowlist) | Terima hanya nilai yang ada di daftar tetap, misalnya `id` atau `en` | Cocok untuk pilihan bahasa atau template |
| Normalisasi dan cek awalan | Ubah ke path absolut, pastikan masih di dalam folder dasar | Wajib bila nama file memang harus dari input |
| Nama file buatan sistem | Simpan upload dengan nama acak, bukan nama asli | Menutup celah di sisi penulisan file |
| Hak akses proses minimal | Jalankan aplikasi dengan user terbatas | Membatasi file yang bisa dibaca bila celah lolos |
| WAF | Memblokir pola serangan yang dikenal | Lapisan tambahan, bukan pengganti perbaikan kode |

Untuk lapisan normalisasi, di PHP polanya kira-kira seperti ini:

```
$dasar = realpath('/var/www/data/invoice');
$path  = realpath($dasar . '/' . basename($_GET['file'] ?? ''));

if ($path === false || strpos($path, $dasar . DIRECTORY_SEPARATOR) !== 0) {
    http_response_code(404);
    exit;
}
readfile($path);
```

`basename()` membuang bagian folder dari input, dan `realpath()` mengubah path menjadi bentuk absolut yang sudah dinormalkan, lalu mengembalikan `false` bila file tidak ada. Hasilnya dicek apakah masih diawali folder dasar. Kombinasi ini menolak upaya keluar dari folder meskipun input ditulis dengan cara yang tidak terduga. Bahasa lain punya fungsi serupa, misalnya `path.resolve` di Node.js atau `Path.resolve` di Python.

Di sisi server, pastikan file sensitif tidak berada di dalam document root. File `.env` sebaiknya disimpan satu tingkat di atas folder publik. Proses PHP-FPM atau aplikasi juga sebaiknya berjalan dengan user khusus yang hanya bisa membaca folder aplikasinya sendiri. Prinsip ini dijelaskan lebih jauh di artikel [memahami permission Linux](https://nivelva.com/insight/memahami-permission-linux-chmod-chown-bingung).

WAF seperti [ModSecurity dengan OWASP CRS](https://nivelva.com/insight/modsecurity-owasp-crs) punya aturan untuk mendeteksi pola path traversal yang umum. Anggap ini jaring pengaman. Kode yang rentan tetap harus diperbaiki, karena variasi penulisan baru bisa saja lolos dari aturan.

## Bagaimana mendeteksi percobaan serangan?

Percobaan path traversal biasanya terlihat di access log web server. Cari permintaan yang parameternya berisi urutan titik dan garis miring berulang, versi encoding URL dari karakter tersebut, atau nama file sistem yang tidak ada hubungannya dengan aplikasimu. Lonjakan respons 404 atau 403 dari satu alamat IP pada endpoint unduh juga patut dicurigai.

Bila ternyata ada permintaan seperti itu yang mendapat respons 200 dengan ukuran tidak wajar, anggap file sudah bocor. Ganti semua kredensial yang ada di file tersebut, terutama password database dan kunci API, lalu periksa log database dan layanan terkait.

## Ringkasnya

Path traversal muncul ketika aplikasi mempercayai input pengguna untuk menentukan file mana yang dibuka. Cara paling aman adalah tidak pernah memakai input itu sebagai path: gunakan ID, daftar yang diizinkan, atau normalisasi path dengan pengecekan folder dasar. Tambahkan hak akses minimal dan WAF sebagai lapisan cadangan, dan periksa log secara berkala untuk menangkap percobaan yang sudah terjadi.

## Sumber

- <https://owasp.org/www-community/attacks/Path_Traversal>
- <https://cwe.mitre.org/data/definitions/22.html>
- <https://owasp.org/Top10/A01_2021-Broken_Access_Control/>
- <https://www.php.net/manual/en/function.realpath.php>

---

Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/path-traversal-celah-membaca-file-rahasia-server
Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com
