security.txt untuk Website Personal — Sediakan Pintu Depan yang Jelas bagi Laporan Keamanan

Website personal mungkin kecil, tetapi tetap punya pintu, jendela, dan sesekali engsel yang longgar. Ketika seorang peneliti menemukan masalah keamanan, perbedaan antara laporan yang membantu dan rasa frustrasi dalam diam bisa sesederhana menerbitkan satu file teks kecil.

File itu bernama security.txt. Ia tidak mengamankan server dengan sendirinya dan bukan pengganti patching, monitoring, atau konfigurasi yang teliti. Tugasnya lebih sempit: memberi tahu orang yang berniat baik cara menghubungimu, apa yang dapat mereka harapkan, dan di mana batasannya.

Apa yang Sebenarnya Dilakukan security.txt

security.txt adalah dokumen kontak standar yang dijelaskan dalam RFC 9116. Peneliti keamanan dan automated tools mencarinya di /.well-known/security.txt. Bayangkan file ini sebagai kartu kontak darurat yang ditempel dekat pintu masuk gedung. Kartu tersebut tidak memasang kunci yang lebih kuat, tetapi mencegah orang yang melihat asap berkeliling ke setiap lorong untuk mencari pemilik gedung.

Tanpa jalur yang dipublikasikan, pelapor mungkin mencoba akun sosial lama, menebak alamat email, mengirim komentar publik, atau menyerah. File yang jelas mengurangi ketidakpastian itu. Kamu juga dapat menyampaikan preferensi, misalnya apakah laporan sebaiknya dienkripsi, bahasa apa yang kamu pahami, dan di mana disclosure policy milikmu berada.

File Paling Ringkas yang Tetap Berguna

File praktis dapat dimulai dengan dua gagasan wajib: kontak yang berfungsi dan tanggal kedaluwarsa. Kontak bisa berupa alamat email atau form HTTPS. Tanggal kedaluwarsa memberi tahu tools dan peneliti bahwa petunjuk tersebut masih dirawat, bukan ditinggalkan bertahun-tahun lalu.

Contact: mailto:[email protected]
Expires: 2027-08-14T00:00:00Z
Preferred-Languages: en, id, de
Canonical: https://example.com/.well-known/security.txt

Ganti domain dan inbox contoh dengan alamat yang benar-benar kamu pantau. Pilih masa berlaku yang cukup panjang, tetapi jangan terlalu jauh sampai file ini terlupakan. Enam sampai dua belas bulan adalah ritme pemeliharaan yang masuk akal. Masukkan pembaruannya ke kalender yang sama dengan pengingat domain, certificate, dan backup.

Field Berguna Tanpa Janji Berlebihan

Field Contact dapat muncul lebih dari sekali sehingga kamu bisa menyediakan email sekaligus web form. Encryption mengarah ke public key jika kamu mampu menerima laporan sensitif secara aman. Acknowledgments menautkan halaman apresiasi bagi orang yang membantu, sedangkan Policy mengarah ke aturan responsible testing. Ada pula Hiring, walaupun kebanyakan website personal tidak memerlukannya.

Publikasikan hanya field yang sanggup kamu dukung. Inbox “security” yang tidak dipantau lebih buruk daripada alamat biasa yang kamu baca setiap hari. Jangan pula menjanjikan respons 24 jam atau hadiah uang jika kamu tidak mampu memenuhinya secara konsisten. Pernyataan sederhana seperti “Aku berusaha mengakui laporan dalam tujuh hari” lebih dapat dipercaya daripada target layanan hebat yang hanya ada di atas kertas.

Tulis Disclosure Policy yang Manusiawi

File teks adalah penunjuk jalan; halaman policy memberikan konteks. Jelaskan sistem yang masuk scope, pengujian yang dilarang, informasi yang perlu ada dalam laporan, dan cara kamu akan berkomunikasi. Untuk website personal, scope dapat mencakup domain utama dan first-party subdomain, tetapi mengecualikan layanan pihak ketiga.

Minta peneliti menghindari pelanggaran privasi, perusakan data, denial-of-service testing, social engineering, dan akses data melebihi kebutuhan untuk membuktikan masalah. Ajak mereka menyertakan URL terdampak, langkah reproduksi, dampak yang diamati, dan proof of concept yang aman. Ini seperti meninggalkan petunjuk perbaikan di samping sepeda: semakin jelas alat dan batasannya, semakin kecil kemungkinan bantuan justru menciptakan masalah kedua.

Publikasikan di Lokasi yang Tepat

Lokasi standarnya sudah tetap: https://example.com/.well-known/security.txt. Salinan lama boleh tersedia di /security.txt, tetapi route /.well-known/ adalah lokasi yang authoritative. Sajikan melalui HTTPS dengan content type berbasis teks dan jangan menyembunyikannya di balik autentikasi, cookie banner, atau aplikasi yang hanya berjalan dengan JavaScript.

Untuk static site, buat direktorinya dan commit file bersama public assets lain. Pada Nginx, location langsung dapat memperjelas respons:

location = /.well-known/security.txt {
    default_type text/plain;
    try_files /.well-known/security.txt =404;
}

Jika framework menangkap semua request, tambahkan pengecualian untuk path ini atau letakkan file di public directory miliknya. Hindari rangkaian redirect yang melintasi domain tidak terkait. Nilai Canonical harus sama dengan lokasi HTTPS final tempat file disajikan.

Signing Itu Opsional, Akurasi Tidak

RFC 9116 mendukung konten yang ditandatangani secara digital. Signature dapat membantu menunjukkan bahwa instruksi tersebut autentik, terutama bagi organisasi besar dengan workflow PGP yang mapan. Untuk website personal kecil, file tanpa signature yang dikirim melalui HTTPS terkonfigurasi dengan benar sering menjadi titik awal yang wajar.

Jangan biarkan kerumitan signing menunda jalur kontak yang berguna. Signature sempurna yang membungkus tanggal kedaluwarsa atau inbox mati tidak membantu siapa pun. Akurasi operasional lebih penting: pertahankan penerima tetap aktif, lindungi inbox dengan autentikasi kuat, batasi orang yang dapat mengakses laporan, dan perlakukan attachment atau kode proof of concept sebagai input yang tidak tepercaya.

Uji Hasil Publiknya

Setelah publikasi, uji apa yang diterima orang luar alih-alih hanya memercayai file lokal. Perintah berikut menampilkan status, header, redirect, dan isi respons:

curl -i https://example.com/.well-known/security.txt
curl -L https://example.com/.well-known/security.txt

Harapkan respons sukses, plain text yang terbaca, serta instruksi terkini yang persis. Jika website di-self-host, periksa dari luar home network. Setelah itu, uji metode kontaknya. Kirim pesan aman dan pastikan spam filtering, alias, serta forwarding rules benar-benar mengantarkannya. Sebuah jalur baru nyata ketika pesan sampai kepada manusia.

Siapkan Proses Sebelum Laporan Datang

Menerbitkan detail kontak menciptakan tanggung jawab untuk merespons dengan tenang. Siapkan proses ringan: akui penerimaan, simpan laporan asli, reproduksi masalah secara aman, perkirakan severity, perbaiki dan verifikasi perubahan, lalu sepakati waktu disclosure. Tidak semua perilaku mengejutkan adalah vulnerability, tetapi setiap laporan yang sopan pantas mendapatkan jawaban yang sopan.

Jangan meminta pelapor mengirim secret yang tidak perlu mereka bagikan. Jika masalah menyangkut personal data, minimalkan salinan dan pindahkan percakapan ke encrypted channel bila tersedia. Simpan catatan singkat agar kamu dapat memahami apakah root cause berasal dari update yang terlewat, default yang tidak aman, credential terekspos, atau asumsi desain yang sudah tidak berlaku.

File Kecil yang Memperbaiki Seluruh Percakapan

security.txt bukan infrastruktur yang glamor. Ia lebih mirip memberi label pada kotak circuit breaker: pekerjaan pemeliharaan kecil yang menjadi sangat berharga tepat ketika ada masalah. File ini membantu peneliti menjangkau orang yang tepat, membantumu menerima konteks yang cukup, dan menetapkan batas sebelum urgensi mengacaukan percakapan.

Mulailah dengan kontak yang dipantau, tanggal kedaluwarsa, bahasa pilihan, dan canonical URL. Tambahkan policy singkat ketika siap, uji path dari internet publik, lalu jadwalkan pembaruan. Jika kamu mengelola website personal, periksa apakah /.well-known/security.txt milikmu sudah ada hari ini. Ceritakan field yang kamu sertakan atau kesulitan yang kamu temui di kolom komentar agar pemilik website kecil lain juga dapat membangun pintu depan yang lebih jelas.