Sistem Saya Tidak Diretas, tapi Data Tetap Bocor

Gue pernah mencari “siapa yang meretas sistem” ketika menemukan data pengguna di tempat yang tidak seharusnya. Setelah ditelusuri, tidak ada exploit dramatis. Data itu terkirim lewat log debugging, masuk ke layanan analytics, lalu tersimpan lebih lama daripada yang kami sadari.

Sistem tidak diretas. Kami sendiri yang terlalu banyak bercerita.

Kebocoran yang terlihat normal

console.log(response) bisa membawa email, ID internal, bahkan token. Screenshot dashboard bisa masuk ke issue tracker. Error monitoring bisa menyimpan request body. Script pihak ketiga bisa menerima URL yang berisi identifier. Masing-masing terlihat kecil; digabungkan menjadi jejak data yang lengkap.

Langkah pertama bukan membeli alat baru. Cari semua tempat data meninggalkan boundary aplikasi: log, analytics, crash reporter, email, backup, staging, dan browser storage.

Redaksi data harus default. Allowlist field yang boleh dicatat lebih aman daripada blacklist field rahasia yang sering lupa diperbarui. Secret juga bukan sekadar disimpan di environment variable; pastikan tidak ikut tercetak saat build atau error.

Privacy adalah keputusan teknis

Tentukan data apa yang benar-benar dibutuhkan, berapa lama disimpan, siapa yang boleh melihat, dan bagaimana pengguna meminta penghapusan. Kalau jawaban untuk “mengapa kita menyimpan ini?” adalah “siapa tahu nanti berguna”, itu sinyal untuk berhenti.

Kebocoran sering terjadi bukan karena satu penyerang jenius, tetapi karena terlalu banyak sistem kecil yang dipercaya. Minimalkan data yang dikumpulkan, batasi akses, dan uji log seperti menguji endpoint.

---

Audit data yang keluar, bukan hanya pintu masuk

Threat model biasanya fokus pada request yang masuk. Padahal data sering bocor melalui jalur yang dianggap “internal”: log aggregation, observability vendor, export CSV, backup, dan environment staging. Masing-masing memiliki permission, retention, dan daftar orang yang bisa mengakses.

Gue menyarankan data inventory sederhana. Untuk setiap field sensitif, catat sumber, tujuan, masa simpan, pemilik, dan apakah nilainya di-redact. Lakukan sampling log production secara berkala dengan akses terbatas. Jangan menunggu audit tahunan untuk menemukan email di error message.

Third-party script juga perlu diperlakukan seperti pihak yang menerima data. Kirim event yang diperlukan saja. Jangan memasukkan email, token, atau identifier mentah ke URL karena URL dapat muncul di history, referrer, analytics, dan proxy log.

Ketika menemukan kebocoran, rotasi credential yang mungkin ikut terlihat, hapus salinan yang tidak diperlukan, dan dokumentasikan timeline. Jangan hanya menghapus baris log lalu menganggap masalah selesai. Cari kenapa data itu bisa masuk ke sana dan buat test atau lint rule agar pola yang sama tertangkap lebih awal.

Privacy bukan fitur halaman legal. Ia adalah perilaku default sistem.

Sumber

• https://owasp.org/www-project-top-ten/
• https://www.nist.gov/privacy-framework
• https://gdpr.eu/article-5-how-to-process-personal-data/