Generator Security.txt

security.txt adalah praktik terbaik keamanan web yang secara resmi distandardisasi oleh IETF (Internet Engineering Task Force) dalam RFC 9116, dirancang untuk memberikan situs web cara yang terpadu dan standar untuk mempublikasikan informasi kontak keamanan. Sederhananya, itu adalah file teks yang ditempatkan di jalur tetap di situs web, memberi tahu peneliti keamanan (peretas topi putih): "Jika Anda menemukan kerentanan keamanan di situs web saya, inilah cara menghubungi kami, inilah kunci publik enkripsi kami, inilah kebijakan pengungkapan kami, kami menyambut laporan Anda."

Sebelum standar security.txt ada, informasi kontak keamanan situs web tidak teratur. Beberapa situs web tidak memiliki informasi kontak keamanan sama sekali, beberapa menguburnya di halaman yang tidak jelas, beberapa hanya mencantumkan email info@ yang tidak dijaga, dan beberapa membutuhkan pencarian melelahkan di LinkedIn untuk menemukan tim keamanan. Ini menyebabkan masalah serius: ketika peneliti keamanan dengan itikad baik menemukan kerentanan, mereka sering kali tidak dapat menemukan saluran yang benar untuk melaporkannya. Hasilnya—banyak kerentanan diam-diam diabaikan, dibiarkan tidak diperbaiki, sampai ditemukan dan dieksploitasi oleh peretas jahat. security.txt lahir untuk menyelesaikan masalah "terakhir mil" ini.

Konsep security.txt pertama kali diusulkan oleh peneliti keamanan EdOverflow dan Yakov Shafranovich pada tahun 2017 dan dengan cepat mendapatkan dukungan industri yang luas. Pada April 2022, security.txt secara resmi disetujui oleh IETF sebagai RFC 9116, menjadi standar keamanan web yang diakui secara internasional. Saat ini, perusahaan teknologi besar seperti Google, GitHub, Meta (Facebook), LinkedIn, dan Cloudflare, serta lembaga pemerintah termasuk Pemerintah Inggris, CISA AS (Badan Keamanan Siber dan Infrastruktur), Pemerintah Prancis, Pemerintah Italia, Pemerintah Belanda, dan Pusat Keamanan Siber Australia, telah mendeploy security.txt di situs web resmi mereka dan secara publik merekomendasikan organisasi lain untuk mengadopsinya.

Desain inti file security.txt sangat sederhana—ini adalah file teks biasa yang terdiri dari baris dalam format "nama-bidang: nilai", mirip dengan format header HTTP. Standar mendefinisikan dua bidang wajib: Contact (informasi kontak keamanan, yang bisa berjumlah banyak) dan Expires (waktu kedaluwarsa file); serta beberapa bidang opsional: Encryption (URL kunci publik enkripsi PGP), Acknowledgments (URL halaman ucapan terima kasih), Policy (URL kebijakan pengungkapan kerentanan), Hiring (URL lowongan keamanan), Canonical (URL kanonik file), Preferred-Languages (bahasa laporan yang didukung), CSAF (URL metadata penyedia Common Security Advisory Framework). Format sederhana ini memudahkan baik manusia maupun mesin untuk mengurai.

Mengapa mendeploy security.txt sangat penting? Pertama, ini menurunkan hambatan pelaporan kerentanan. Peneliti keamanan tidak perlu menghabiskan waktu signifikan untuk menemukan informasi kontak—mereka dapat menemukan saluran pelaporan yang benar dengan satu klik. Kedua, ini menunjukkan sikap proaktif organisasi terhadap keamanan—situs web dengan security.txt pada dasarnya mengatakan "Kami menganggap serius keamanan dan menyambut laporan yang bertanggung jawab." Ketiga, ini mengurangi risiko kerentanan diungkapkan secara publik atau dieksploitasi: dengan saluran formal, peneliti tidak akan memilih untuk mengungkapkan kerentanan secara publik langsung di Twitter atau GitHub karena mereka tidak dapat menghubungi siapa pun. Keempat, dalam banyak persyaratan regulasi industri (keuangan, kesehatan, pemerintah), membangun saluran pengungkapan kerentanan telah menjadi persyaratan kepatuhan.

Ada beberapa detail kunci yang perlu diperhatikan saat mendeploy security.txt. Pertama, jalur harus benar: jalur standar adalah /.well-known/security.txt dan Anda juga dapat menempatkan salinan di /security.txt di direktori root sebagai cadangan. Direktori .well-known di sini adalah direktori "sumber daya dikenal" standar yang didefinisikan oleh RFC 8615, di mana file standar lain seperti robots.txt juga ditempatkan di lokasi terkait. Kedua, harus disajikan melalui HTTPS—HTTP teks biasa dianggap tidak aman. Ketiga, Content-Type harus text/plain, bukan text/html atau jenis lain. Keempat, jangan melakukan pengalihan lintas domain untuk security.txt—jika https://example.com/.well-known/security.txt dialihkan ke https://other-domain.com/security.txt, peneliti dan alat otomatis akan menganggapnya mencurigakan. Kelima, ingat untuk mengatur bidang Expires dan memperbaruinya secara teratur; security.txt yang kedaluwarsa akan dianggap memiliki informasi yang tidak dapat diandalkan.

Bidang Contact adalah bidang terpenting dalam security.txt dan satu-satunya bidang yang benar-benar esensial (Expires juga wajib tetapi hanya stempel waktu). Contact mendukung tiga format URI: mailto: untuk alamat email, https: untuk tautan web (seperti halaman formulir laporan keamanan), tel: untuk nomor telepon. Sangat disarankan untuk menyediakan setidaknya satu email mailto dan satu tautan formulir https—formulir mencegah spam bot, sedangkan email lebih nyaman bagi peneliti untuk mengirim laporan terenkripsi secara langsung. Beberapa kontak dapat dicantumkan di beberapa baris, misalnya secara bersamaan menyediakan email tim keamanan, email kepala keamanan, dan tautan platform kerentanan pihak ketiga.

Meskipun bidang Encryption bersifat opsional, ini sangat penting dalam praktik. Ketika peneliti keamanan menemukan kerentanan kritis (seperti kebocoran data pengguna atau eksekusi kode jarak jauh), mereka sama sekali tidak ingin mengirim detail kerentanan dalam email teks biasa—karena email melewati beberapa server selama transmisi, setiap lompatan dapat disadap. Enkripsi kunci publik PGP (Pretty Good Privacy) adalah standar industri untuk komunikasi aman. Anda hanya perlu membuat pasangan kunci PGP, menempatkan kunci publik di situs web Anda (misalnya di /.well-known/pgp-key.txt) dan memasukkan URL tersebut di bidang Encryption. Peneliti mengenkripsi konten laporan dengan kunci publik Anda dan hanya mereka yang memegang kunci privat yang sesuai yang dapat mendekripsi dan membacanya.

Bidang Policy menautkan ke halaman Kebijakan Pengungkapan Kerentanan (Vulnerability Disclosure Policy, VDP) Anda, yang merupakan kunci untuk membangun kepercayaan peneliti. VDP yang baik harus menyatakan dengan jelas: cakupan pengujian (sistem mana yang dalam cakupan pengujian dan mana yang tidak), metode pengujian yang diizinkan (misalnya pengujian SQL injection/XSS diizinkan tetapi DDoS/rekayasa sosial/mengakses data pengguna nyata dilarang), waktu respons yang dijanjikan (misalnya "Kami akan mengonfirmasi penerimaan laporan dalam 3 hari kerja"), apakah Anda menawarkan hadiah, dan komitmen perlindungan hukum (secara eksplisit menyatakan tidak akan menuntut peneliti dengan itikad baik yang mengikuti aturan). Ada banyak templat VDP yang tersedia secara internasional sebagai referensi dan CISA AS juga menyediakan templat VDP sumber terbuka.

Selain kontak keamanan itu sendiri, security.txt memiliki beberapa bidang "kejutan". Bidang Acknowledgments membangun Security Hall of Fame—berterima kasih secara publik kepada peneliti yang membantu Anda menemukan kerentanan, mengakui karya mereka dan juga berfungsi sebagai pembangunan komunitas. Bidang Hiring adalah desain yang sangat cerdas: orang yang dapat menemukan kerentanan di situs web Anda pada dasarnya adalah bakat keamanan yang sangat baik dan menempatkan tautan rekrutmen di security.txt adalah saluran paling tepat untuk merekrut bakat keamanan. Banyak perusahaan telah merekrut insinyur keamanan yang sangat baik melalui security.txt. Bidang Canonical adalah pertimbangan keamanan—mencegah penyerang memalsukan security.txt Anda di domain lain.

Mengenai kekhawatiran spam yang umum, dalam praktiknya sebagian besar organisasi yang telah mendeploy security.txt melaporkan peningkatan spam yang tidak signifikan. Ini karena: pertama, pengirim spam biasanya tidak mendapatkan alamat email dengan merayapi security.txt; kedua, tautan formulir https:// dapat digunakan alih-alih langsung menempatkan email mailto dan menambahkan CAPTCHA ke formulir dapat sepenuhnya memblokir bot; ketiga, email khusus keamanan (misalnya security@) biasanya memiliki penyaringan spam yang ketat yang dikonfigurasi. Sebaliknya, biaya kehilangan laporan kerentanan kritis karena kurangnya saluran kontak keamanan jauh melebihi potensi peningkatan jumlah spam kecil.

Generator ini dibangun dengan kepatuhan ketat terhadap standar RFC 9116 dan semua format output dinormalisasi: bidang Contact secara otomatis mengenali awalan, bidang Expires menggunakan format waktu UTC standar ISO 8601 dan Preferred-Languages secara otomatis diatur berdasarkan bahasa yang Anda gunakan. Konten yang dihasilkan dapat langsung disalin dan dideploy ke jalur /.well-known/security.txt tanpa modifikasi apa pun. Selain itu, semua konfigurasi dilakukan secara lokal di browser Anda dan tidak pernah dikirim ke server mana pun—informasi kontak keamanan Anda selalu tetap di perangkat Anda. Mendeploy security.txt hanya membutuhkan 5 menit, tetapi saluran komunikasi keamanan yang dibangunnya dapat membantu Anda menghindari insiden keamanan serius di masa depan.