1 Baris Kode Lupa Hapus Bikin 40 Juta Pelanggan Terbaca

Kenapa Satu File Backup Bisa Jadi Bencana

Bayangkan punya brankas berisi data 40 juta pelanggan, lalu menaruhnya di teras rumah tanpa kunci. Itulah yang terjadi ketika file backup database WordPress (.sql, .sql.gz, .zip) diletakkan di folder /wp-content/uploads/ atau root web tanpa proteksi. Satu baris kode yang lupa dihapus dari skrip backup otomatis bisa membuat file tersebut terekspos ke publik — dan mesin pencari akan mengindeksnya dalam hitungan jam.

Ringkasan Eksekutif:

• Penyebab utama: File backup SQL ditaruh di folder yang dapat diakses publik (/wp-content/uploads/ atau root) tanpa aturan .htaccess yang memblokir akses langsung.
• Celah yang dieksploitasi: Google dork seperti site:domain.com ext:sql atau inurl:wp-content/uploads filetype:sql menemukan file dalam hitungan detik.
• Mitigasi wajib: Pindahkan backup ke luar docroot, blokir directory listing, dan rotasi otomatis dengan penghapusan file lama.

Anatomi Insiden: 1 Baris Kode yang Lupa Dihapus

Banyak pemilik bisnis memakai plugin backup atau skrip kustom untuk menyimpan database secara berkala. Skrip tersebut sering menulis file ke folder yang “mudah dijangkau” — biasanya /wp-content/uploads/ karena folder itu sudah writable oleh web server. Masalah muncul ketika skrip tidak menghapus file setelah diunduh, atau tidak memberi nama acak, dan tidak ada proteksi di level server.

Pola Akses File yang Salah

• Lokasi default berbahaya: /wp-content/uploads/backup-2025-01-15.sql — folder ini memang publik untuk gambar, tapi juga membuka akses ke file lain jika tidak dibatasi.
• Root directory tanpa proteksi: File seperti backup.sql atau db-dump.zip di public_html/ dapat diakses langsung via https://domain.com/backup.sql.
• Nama file mudah ditebak: Pola tanggal atau nama domain membuat penyerang bisa menebak URL tanpa perlu melihat daftar direktori.
• Tanpa autentikasi: Tidak ada pengecekan login atau token sebelum file disajikan — web server langsung mengirimkan isi file.

Permission Server yang Memperparah

Di server Linux, file backup sering dibuat dengan permission 644 (bisa dibaca semua user) dan folder 755. Jika web server berjalan sebagai user yang sama dengan pembuat file, atau jika ada salah konfigurasi umask, file bisa dibaca oleh proses lain. Yang lebih fatal: jika directory listing aktif (opsi Options +Indexes di Apache), siapa pun bisa melihat daftar semua file di folder tersebut.

Statistik Mengkhawatirkan: Berdasarkan laporan dari lembaga riset keamanan, lebih dari 30% kebocoran data massal di sektor e-commerce dan layanan publik disebabkan oleh file backup yang terekspos, bukan serangan hacking canggih. Sebagian besar ditemukan dalam waktu kurang dari 24 jam setelah file diunggah.

Cara Kerja Google Dork Menemukan File Backup

Mesin pencari mengindeks URL yang dapat diakses publik. Jika file backup tidak dilindungi, crawler akan menemukannya melalui tautan internal, sitemap, atau bahkan dari direktori yang menampilkan daftar file. Penyerang cukup menggunakan Google dork — kueri pencarian khusus — untuk menyaring hasil.

Contoh Kueri Dork yang Sering Dipakai

• site:domain.com ext:sql: Mencari semua file berakhiran .sql di domain tertentu.
• inurl:wp-content/uploads filetype:sql: Menargetkan folder uploads WordPress yang berisi file SQL.
• intitle:"index of" backup: Menemukan direktori tanpa halaman utama yang menampilkan daftar file backup.
• intext:"-- MySQL dump" ext:sql: Mencari file dump MySQL yang tidak sengaja terindeks.

Setelah URL ditemukan, penyerang tinggal mengunduh file dan membuka isinya dengan editor teks biasa. Data seperti nama, email, nomor telepon, alamat, hingga hash password langsung terbaca.

Audit Cepat: Cek URL Langsung Tanpa Tools

Pemilik bisnis non-teknis tetap bisa melakukan audit awal. Caranya: coba akses URL yang mencurigakan langsung di browser. Jika file backup dapat diunduh tanpa login, berarti ada kebocoran.

Langkah Audit Praktis

1. Daftar URL yang mungkin: Periksa pola seperti https://domainanda.com/backup.sql, https://domainanda.com/wp-content/uploads/backup.zip, atau https://domainanda.com/db-dump.sql.
2. Buka di browser: Jika muncul dialog unduhan atau teks dump database, hentikan — file terekspos.
3. Cek directory listing: Kunjungi https://domainanda.com/wp-content/uploads/. Jika muncul daftar file, berarti listing aktif dan semua file di dalamnya bisa diakses.
4. Gunakan Google search: Ketik site:domainanda.com ext:sql di Google. Jika ada hasil, segera tindak lanjuti.
5. Periksa log akses: Minta hosting melihat log server untuk pola permintaan ke file .sql atau .zip dari IP asing.

Perbandingan: Backup di Folder Publik vs Luar Docroot

Mitigasi: 3 Langkah Wajib

1. Pindahkan backup keluar docroot: Simpan file di direktori seperti /home/user/backups/ yang tidak berada di bawah public_html. Web server tidak akan pernah menyajikannya.
2. Blokir directory listing dan akses file sensitif: Tambahkan aturan di .htaccess (Apache) atau konfigurasi Nginx untuk menolak akses ke ekstensi .sql, .zip, .gz, dan matikan Options -Indexes.
3. Rotasi otomatis dengan penghapusan: Atur skrip backup untuk menghapus file lama setelah periode tertentu (misal 7 hari) dan gunakan penamaan acak. Pastikan skrip berjalan dengan user terbatas dan tidak meninggalkan file di folder publik.

FAQ

Apakah file backup yang sudah terindeks Google masih bisa dihapus dari hasil pencarian?

Bisa, tapi tidak instan. Setelah file dihapus dari server, gunakan alat “Remove URL” di Google Search Console untuk mempercepat penghapusan dari indeks. Namun, data yang sudah terunduh tidak bisa ditarik kembali — fokus pada pemberitahuan ke pelanggan dan rotasi kredensial.

Apakah plugin backup WordPress otomatis aman?

Tidak selalu. Beberapa plugin menyimpan file di folder yang dapat diakses publik secara default. Periksa pengaturan plugin dan pastikan opsi “simpan di luar web root” atau “kirim ke penyimpanan cloud” diaktifkan. Selalu verifikasi dengan mengakses URL file backup — jika bisa diunduh, plugin tersebut berisiko.

Kesimpulan

Kebocoran 40 juta data pelanggan sering dimulai dari kelalaian kecil: satu file backup yang lupa dipindahkan. Dengan memahami pola akses file, permission server, dan cara audit cepat, Anda bisa mencegah bencana ini. Jangan tunggu sampai data pelanggan bocor. Konsultasikan pengamanan website bisnis Anda dengan tim Avoca Code di avocacode.id — kami membantu audit keamanan, migrasi backup ke luar docroot, dan implementasi rotasi otomatis yang aman.