Laporan kerentanan dapat kehilangan nilai bahkan sebelum triase dimulai jika pelapor tidak dapat menemukan kontak yang masih aktif dan dikendalikan organisasi. RFC 9116 menangani persoalan perutean itu melalui security.txt, file teks yang dapat diproses mesin dan diterbitkan pada lokasi HTTPS yang dapat diprediksi.
File ini tidak memberikan izin pengujian, tidak membentuk program bug bounty, dan tidak membuktikan bahwa penerima yang tercantum dapat dipercaya. Perannya lebih sempit: menerbitkan metadata pengungkapan kerentanan dalam format yang dapat diambil secara konsisten oleh manusia maupun perangkat otomatis.
Lokasi kanonis berada di bawah /.well-known/
Untuk layanan web, RFC 9116 menempatkan resource pada:
https://example.com/.well-known/security.txtLokasi /.well-known/ bersifat normatif. /security.txt pada tingkat teratas dapat tersedia untuk kompatibilitas legacy, tetapi ketika kedua lokasi ada, resource pada well-known yang digunakan.
Pengambilan dilakukan melalui HTTPS. Respons berupa teks biasa yang dikodekan sebagai UTF-8 dengan text/plain sebagai media type. Batasan ini menjaga format tetap sederhana sekaligus menyerahkan integritas transport pada koneksi HTTPS.
Cakupan mengikuti nama domain atau alamat IP yang digunakan untuk mengambil file. File dari example.com tidak otomatis berlaku untuk api.example.com, dan file pada subdomain tidak otomatis mengatur domain induknya. Organisasi dapat menjelaskan cakupan produk atau layanan yang lebih luas melalui kebijakan pengungkapan, tetapi cakupan pengambilan file tetap terbatas.
Contact dan Expires menjadi field operasional wajib
File yang valid memerlukan setidaknya satu field Contact. Nilainya berupa URI, sehingga kontak email memakai mailto: dan bukan alamat polos. Beberapa field Contact dapat menyatakan beberapa kanal pelaporan, disusun berdasarkan urutan preferensi.
RFC 9116 juga mewajibkan Expires. Nilainya berupa tanggal dan waktu yang menunjukkan saat file tidak lagi diperlakukan sebagai data terkini. Spesifikasi merekomendasikan timestamp tersebut ditetapkan kurang dari satu tahun ke depan.
File ringkas dapat berbentuk:
Contact: mailto:security@example.com
Expires: 2027-03-01T00:00:00Z
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policyCanonical menunjukkan URI tempat file yang sama dimaksudkan sebagai sumber otoritatif. Jika file memuat field Canonical tetapi tidak satu pun cocok dengan URI yang dipakai untuk mengambilnya, RFC 9116 menyatakan bahwa isinya sebaiknya tidak dipercaya.
Policy dapat menunjuk ke kebijakan pengungkapan kerentanan yang memuat rincian yang tidak cocok ditempatkan dalam file ringkas yang dapat diproses mesin, seperti batas pengujian, ekspektasi pelaporan, atau ketentuan coordinated disclosure.
Field opsional membawa metadata proses
Format ini mendefinisikan field tambahan untuk alur pengungkapan yang umum. Encryption dapat menunjuk ke kunci atau material lain untuk melindungi laporan. Acknowledgments dapat menautkan halaman yang memberikan pengakuan kepada pelapor. Hiring dapat menunjukkan informasi lowongan terkait keamanan. Preferred-Languages dapat menyatakan bahasa alami yang diprioritaskan organisasi untuk menerima laporan.
Field tersebut tidak menggantikan resource yang dirujuk. URI Policy tetap memerlukan kebijakan yang dipelihara, sedangkan URI Encryption tetap memerlukan material kriptografi yang dapat digunakan. Pointer yang sintaksnya benar tetapi mengarah ke data usang atau tidak dapat diakses tetap menghasilkan jalur pelaporan yang lemah secara operasional.
Nama field tidak peka huruf besar-kecil. Setiap field berada pada baris tersendiri, sedangkan komentar diawali #. Grammar sengaja dibatasi agar parser tidak perlu menebak struktur dari prosa.
Kedaluwarsa menjadikan pemeliharaan bagian dari protokol
Kontak keamanan yang menjadi usang tanpa penanda dapat mengarahkan detail kerentanan sensitif ke mailbox yang ditinggalkan atau pihak yang tidak terkait. Expires membuat kondisi usang terlihat oleh konsumen alih-alih membiarkan freshness bersifat implisit.
Field tersebut tidak memperbarui dirinya sendiri. Operator tetap memerlukan proses pemeliharaan yang memeriksa endpoint kontak, halaman kebijakan, material enkripsi, URI kanonis, dan timestamp kedaluwarsa. File yang masih dapat diakses setelah tanggal kedaluwarsa tidak setara dengan kanal pengungkapan yang masih aktif.
Kondisi ini juga membuat publikasi tidak tepat diperlakukan sebagai tugas deployment satu kali. State yang berguna bukan sekadar “file tersedia”, melainkan “file terkini menunjuk ke resource terkini yang dikendalikan organisasi yang dituju.”
Situs yang dikompromikan dapat mengalihkan jalur pelaporan
security.txt disajikan oleh infrastruktur web yang sama dengan infrastruktur yang mungkin dikompromikan penyerang. Kendali atas situs dapat memungkinkan perubahan file atau pembuatan redirect menuju informasi kontak yang dikendalikan penyerang.
Karena itu, RFC 9116 memperlakukan autentisitas sebagai persoalan terpisah. Field Canonical dapat membantu mengikat konten ke lokasi yang diharapkan, dan spesifikasi mendukung tanda tangan cleartext OpenPGP pada file. Konsumen tetap perlu menilai redirect dan indikasi manipulasi lain, bukan menganggap pengambilan yang berhasil sebagai bukti kendali organisasi.
Batas ini sangat penting dalam respons insiden. Kontak pengungkapan yang diterbitkan host yang telah dikompromikan dapat termasuk resource yang mampu diubah penyusup. Spesifikasi ditujukan untuk respons kerentanan dan memberi peringatan terhadap penggunaan mekanisme ini sebagai trust anchor untuk respons insiden.
Publikasi tidak memberikan izin pengujian keamanan
Keberadaan security.txt tidak memberikan izin untuk melakukan scan, probing, eksploitasi, atau pengujian lain terhadap sistem. Ketiadaannya juga tidak dengan sendirinya melarang aktivitas. Otorisasi berasal dari kebijakan yang berlaku, kontrak, ketentuan program, atau kontrol hukum dan organisasi lainnya.
Pemisahan tersebut menjaga pencarian kontak tetap berbeda dari cakupan pengujian. Field Policy dapat mengarahkan pelapor ke aturan eksplisit, tetapi file kontak yang dapat diproses mesin bukan pengganti aturan tersebut.
Pemisahan yang sama berlaku untuk bug bounty. Organisasi dapat menerbitkan security.txt tanpa menawarkan kompensasi, dan program bounty dapat menetapkan syarat yang melampaui apa pun yang direpresentasikan dalam file.
Parser perlu memperlakukan input sebagai data tidak tepercaya
Endpoint security.txt publik dapat mengembalikan input rusak atau berukuran tidak wajar. RFC 9116 membahas parsing defensif dan mencatat bahwa implementasi dapat menerapkan batas, misalnya menolak file yang lebih besar dari 32 KB, field lebih panjang dari 2.048 karakter, atau file dengan lebih dari 1.000 baris.
Angka tersebut merupakan pilihan implementasi yang disajikan RFC, bukan batas validitas dalam grammar file. Konsumen yang tangguh juga perlu menangani redirect secara sengaja, memvalidasi skema dan sintaks URI, memproses UTF-8 dengan benar, serta menghindari penggunaan resource rujukan sebagai target fetch tanpa pemeriksaan.
Format yang dapat diproses mesin mengurangi ambiguitas hanya jika parsing tetap ketat. Memperlakukan teks arbitrer sebagai konfigurasi tepercaya justru memindahkan risiko dari pencarian kontak ke tooling yang mengonsumsinya.
Properti utamanya adalah perutean yang dapat diprediksi
security.txt tidak mengamankan aplikasi dan tidak mensertifikasi program pengungkapan. Mekanisme ini menstandardisasi antarmuka kecil tetapi penting antara pelapor dan organisasi: ke mana laporan kerentanan dikirim, kapan data perutean itu kedaluwarsa, serta di mana kebijakan pendukung atau material enkripsi diterbitkan.
Nilai keamanannya bergantung pada operasi yang disiplin di sekitar antarmuka tersebut. HTTPS melindungi pengambilan saat transit, lokasi kanonis mengurangi ambiguitas, kedaluwarsa menandai metadata usang, tanda tangan dapat menambahkan sinyal autentisitas, dan tautan kebijakan yang dipelihara membawa proses manusia yang memang diletakkan di luar file ringkas tersebut.