Security TXT Generator: เผยแพร่ไฟล์ security.txt ตาม RFC 9116 ให้ถูกต้อง

ตีสองแล้ว นักวิจัยด้านความปลอดภัยเพิ่งพบช่องโหว่จริงในเว็บแอปของคุณ เขาอยากทำสิ่งที่ถูกต้องและรายงานอย่างรับผิดชอบ แต่ก่อนอื่นเขาต้องรู้ว่าควรบอกใคร เขาลองหา security contact page ของเว็บคุณ ไม่เจออะไร จากนั้นกวาดดูที่ root เผื่อมีไฟล์ security.txt ก็ยังว่างเปล่า ตอนนี้เขาเหลือสามทางเลือก: ขุด DNS record กับข้อมูล WHOIS หวังว่าจะเจอคนที่ติดต่อได้, เงียบแล้วเดินจากไป, หรือโพสต์เรื่องนี้ต่อสาธารณะ ไฟล์ข้อความเล็ก ๆ ในตำแหน่งที่รู้กันทั่ว จะเปลี่ยนการเดาโชคครั้งนั้นให้กลายเป็นอีเมลหนึ่งฉบับที่ใช้เวลาแค่นาทีเดียว และนั่นคือสิ่งที่ Security TXT Generator ฟรีตัวนี้สร้างให้คุณ

security.txt เป็นมาตรฐานอินเทอร์เน็ตที่ถูกทำให้เป็นทางการในชื่อ RFC 9116 กำหนดไฟล์ที่เครื่องอ่านได้ ซึ่งอธิบายว่าต้องรายงานปัญหาความปลอดภัยของโดเมนหนึ่ง ๆ อย่างไร ไฟล์นี้อยู่ที่ /.well-known/security.txt (และมี fallback ที่ /security.txt) เครื่องมือ สแกนเนอร์ และนักวิจัยจำนวนมากขึ้นเรื่อย ๆ มองหาไฟล์นี้โดยอัตโนมัติ ถึงจะเผยแพร่ได้ง่ายจนแทบไม่ต้องใช้ความพยายาม แต่เว็บส่วนใหญ่ยังไม่มีไฟล์นี้ รวมถึงหลายเว็บขององค์กรที่แน่นอนว่าอยากได้รายงานตอนตีสองนั้น

ในคู่มือนี้ เราจะคุยกันว่าไฟล์นี้สำคัญตรงไหน ไล่ทีละฟิลด์ตาม RFC 9116 ที่ตัว generator รองรับ สาธิตวิธีกรอกฟอร์มและโฮสต์ผลลัพธ์ ปิดท้ายด้วยตัวอย่างการใช้งานจริงและ best practices

ทำไมต้องใช้ Security TXT Generator?

• เปิดทางเดียวที่ชัดเจนให้นักวิจัยติดต่อคุณได้ — บรรทัด Contact ที่ชี้ไปยัง inbox ซึ่งมีคนเฝ้าอยู่ ตัดการเดาทั้งหมดออกจาก responsible disclosure แทนที่จะทวีตหาบัญชี support หรือเปิด issue สาธารณะ นักวิจัยส่งอีเมลไปยังที่อยู่ที่ถูกต้อง และทีมของคุณก็ triage รายงานได้อย่างเป็นระบบ
• ผลลัพธ์เป็นไปตามมาตรฐาน RFC 9116 — เครื่องมือ emit คู่ Field: value บรรทัดละหนึ่งคู่ ตาม syntax ที่ RFC กำหนดไว้เป๊ะ parser อัตโนมัติ, vulnerability scanner และแพลตฟอร์ม bug bounty จึงอ่านไฟล์ของคุณได้โดยไม่สะดุดกับรูปแบบที่ผิด
• ฟิลด์บังคับถูกตรวจสอบให้อัตโนมัติ — RFC 9116 บังคับว่า Contact และ Expires ต้องมี และสองฟิลด์นี้แหละที่คนมักลืมบ่อยที่สุด generator จะเตือนทันทีเมื่อขาด contact หรือ expiry ก่อนคุณ copy output ไปไหน คุณจึงไม่มีทางเผยแพร่ไฟล์ที่ไม่ถูกต้อง
• รองรับฟิลด์สมัยใหม่ ไม่ใช่แค่พื้นฐาน — นอกเหนือจาก Contact, Encryption, Policy และ Expires ฟอร์มยังรองรับ Preferred-Languages, Canonical, Acknowledgments, Hiring และ CSAF ครบทั้งพื้นผิวของมาตรฐาน รวมถึงลิงก์ advisory แบบ machine-readable ที่ใหม่กว่า
• ทำงานฝั่ง client 100% และเป็นส่วนตัว — ทุกอย่างรันในเบราว์เซอร์ของคุณ security contact, ชื่อโดเมน และ policy URL ไม่เคยแตะ server เลย ซึ่งเป็นคุณสมบัติที่เหมาะกับเครื่องมือด้านความปลอดภัยมาก
• ฟรี ทันที และพร้อม copy — ไม่ต้องมี account ไม่ต้องตั้งค่าอะไร ไม่ต้องตามหาไฟล์ template กรอกฟิลด์ กด copy หรือ download แล้วเอาไป deploy ได้เลย

ฟีเจอร์เด่น

มีรายละเอียดน่าสนใจอยู่สองสามข้อ:

• ใส่ Contact ได้หลายรายการ และแนะนำให้ทำ — จะใส่ mailto: address, ฟอร์มเว็บ HTTPS และ URI เบอร์โทรศัพท์ในไฟล์เดียวกันก็ได้ เพื่อให้นักวิจัยเลือกช่องทางที่เขาเชื่อใจ
• ค่า Expires ถูกเขียนเป็น timestamp ISO 8601 เต็มรูปแบบ — กรอกวันที่ในฟอร์ม แล้วเครื่องมือจะ emit รูปแบบเต็มที่มี T23:59:59.000Z ตามที่ RFC คาดหวัง ช่วยคุณเลี่ยง syntax error ที่เจอบ่อย
• คอมเมนต์ถูกเก็บไว้ — บรรทัดที่ขึ้นต้นด้วย # ถือว่าถูกต้องตามมาตรฐาน คุณจึงใส่หมายเหตุให้มนุษย์อ่านได้ ขณะที่ parser มองข้ามไป

วิธีใช้งาน

1. เปิด Security TXT Generator แล้วเริ่มจากฟิลด์ Contact กรอกอีเมล security inbox ของคุณ เครื่องมือจะ render เป็น mailto:[email protected] ให้ เพิ่ม URL หรือฟอร์มติดต่อ HTTPS เป็นรายการต่อ ๆ ไปถ้ามี
2. กรอกฟิลด์ประกอบอื่น ๆ: ลิงก์ไปยังหน้า Policy, ตำแหน่ง Encryption key, Preferred-Languages ที่ทีมรับได้ และฟิลด์ทางเลือกอย่าง Canonical, Acknowledgments, Hiring หรือ CSAF ที่เกี่ยวข้องกับคุณ
3. กำหนดวันที่ Expires เลือกให้สมจริง — หนึ่งปีล่วงหน้าเป็นแนวปฏิบัติที่พบบ่อย — แล้วจดลงปฏิทิน เพราะเครื่องมือจะเติมรูปแบบ timestamp เต็มให้เอง
4. กดปุ่ม copy (หรือ download ไฟล์) แล้ว deploy ที่ทั้ง /.well-known/security.txt และ /security.txt บนโดเมนของคุณ เสิร์ฟผ่าน HTTPS โดย path well-known คือที่ที่ scanner เช็คก่อน ส่วน fallback ที่ root เก็บส่วนที่เหลือ
5. ตรวจสอบจากภายนอก ดึง URL จากนอกเครือข่ายของคุณด้วยเบราว์เซอร์หรือ curl ยืนยันว่า content-type เป็น text/plain แล้วเอาไปรันผ่าน checker ของ security.txt เพื่อยืนยันว่าทุกบรรทัด parse ผ่านสะอาด

อธิบายฟิลด์ RFC 9116 ทีละตัว

Contact — ฟิลด์เดียวที่สำคัญจริง ๆ ฟิลด์บังคับนี้บอกผู้รายงานว่าส่งสิ่งที่พบไปที่ไหน ในทางปฏิบัติ RFC ยอมรับสอง URI scheme คือ mailto: สำหรับอีเมล และ https: สำหรับฟอร์มเว็บ กล่องจดหมายที่มีคนเฝ้าอย่าง mailto:[email protected] คือตัวเลือกคลาสสิก ส่วนฟอร์ม https://example.com/security-contact ทำงานได้ดีเมื่อคุณต้องการระบบ ticket ในการรับเรื่อง การใส่ Contact หลายรายการไม่ผิดและมักฉลาดด้วยซ้ำ เพราะ mail filter ขององค์กรมักกลืนเมลจากผู้ส่งที่ไม่รู้จัก ถ้านักวิจัยติดต่อมนุษย์ไม่ได้ ฟิลด์อื่นทั้งหมดก็เป็นแค่ของประดับ

Expires — ฟิลด์บังคับที่ทุกคนลืม RFC 9116 ตั้งใจบังคับวันหมดอายุ เพื่อไม่ให้ไฟล์เก่าค้างอยู่ตลอดไป security.txt ที่ชี้ไปยังกล่องเมลร้างของพนักงานที่ลาออกไปแล้ว แย่กว่าไม่มีไฟล์เลยด้วยซ้ำ เพราะมันส่งรายงานหายเข้ากลีบเมฆอย่างเงียบ ๆ มาตรฐานจึงบังคับให้คุณสัญญาว่าไฟล์ยังเป็นปัจจุบัน และชุมชนถือว่าไฟล์ที่หมดอายุเป็นสัญญาณแรงว่าไม่มีใครฟังอยู่ ตั้งวันให้สมจริง ใส่ reminder ต่ออายุในปฏิทินทีม แล้วอัปเดตไฟล์ทุกปี — generator ทำให้งานนี้ใช้เวลาแค่สิบวินาที

Policy กับ Encryption ฟิลด์ Policy ลิงก์ไปยังนโยบาย vulnerability disclosure ของคุณ ซึ่งเป็นเอกสารที่บอกว่าอะไรอยู่ในขอบเขต ใช้เวลาตอบนานแค่ไหน และมี safe harbor ให้การวิจัยโดยสุจริตหรือไม่ การลิงก์ไว้หมายความว่านักวิจัยอ่านกติกาก่อนทดสอบต่อ ซึ่งปกป้องทั้งสองฝ่าย ส่วนฟิลด์ Encryption ชี้ไปยัง PGP public key ของคุณ เพื่อให้นักวิจัยเข้ารหัสสิ่งที่พบได้ รายละเอียด exploit จึงไม่ลอยอยู่ในอีเมล plaintext

Preferred-Languages และฟิลด์อื่น ๆ ในครอบครัวเดียวกัน Preferred-Languages ระบุรหัส ISO 639-1 ของภาษาที่ทีมตอบได้ — มีค่ามากสำหรับองค์กรที่ให้บริการผู้ใช้หลายภาษา Canonical ระบุ canonical URL ของไฟล์เพื่อกันสำเนาที่ขัดแย้งกัน Acknowledgments ลิงก์ไปยัง hall of fame ที่ช่วยให้กำลังใจนักวิจัย Hiring ใช้ประกาศตำแหน่งงานด้าน security ส่วน CSAF ชี้ไปยังเอกสาร Common Security Advisory Framework สำหรับองค์กรที่เผยแพร่ advisory แบบ machine-readable

การเซ็นไฟล์ (signing) ใครก็เขียนไฟล์ลงโดเมนที่ตัวเองคุมได้ แต่ security.txt ที่เซ็นด้วย PGP key ของคุณช่วยให้นักวิจัยยืนยันได้ว่า contact นั้นเป็นของคุณจริง ๆ เซ็นสำเนาด้วย cleartext PGP signature เผยแพร่คู่กับไฟล์ธรรมดา แล้วอ้างอิง public key ในฟิลด์ Encryption มันเป็นเรื่องทางเลือก แต่เป็นความต่างระหว่าง "มีคนบอกไว้อย่างนั้น" กับ "รับรองด้วย cryptography แล้ว"

ตัวอย่างฉบับเต็มที่ generator สร้างออกมา พร้อมคำอธิบาย:

# ช่องทางติดต่อเราและวิธีที่เราจัดการรายงาน
Contact: mailto:[email protected]
Contact: https://example.com/security-contact
Encryption: https://example.com/pgp-key.txt
Preferred-Languages: en, th
Policy: https://example.com/security/vulnerability-disclosure
Canonical: https://example.com/.well-known/security.txt
Expires: 2027-01-01T23:59:59.000Z

ตัวอย่างการใช้งานจริง

ผลิตภัณฑ์ SaaS

แอป SaaS มีพื้นผิวโจมตีหนาแน่น ทั้งข้อมูล multi-tenant, API และ flow การเรียกเก็บเงิน การเผยแพร่ security.txt พร้อมลิงก์ policy ที่ชัดเจน บอกนัก pentest และลูกค้าได้ตรง ๆ ว่าควรรายงานสิ่งที่พบอย่างไร และหน้า Acknowledgments เปลี่ยนคนที่รายงานครั้งเดียวให้กลายเป็นพันธมิตรระยะยาว นอกจากนี้ยังแสดงความ mature ระหว่างการตรวจสอบความปลอดภัยระดับองค์กร ที่ผู้ซื้อเริ่มเช็คหาช่องทาง disclosure กันมากขึ้น

เว็บองค์กรและเว็บ marketing

เว็บ marketing แทบไม่มีวิศวกรความปลอดภัยประจำ ซึ่งนั่นแหละคือเหตุผลที่มันต้องการไฟล์นี้ — นักวิจัยที่เจอ XSS ในฟอร์มติดต่อของคุณไม่รู้เลยว่ารายงานควรไปถึงทีม IT ที่อยู่อีกสองแผนก security.txt ที่มีกล่องเมลเดียวซึ่งมีคนเฝ้า ปิดช่องว่างนั้นได้ และฟิลด์ Preferred-Languages ช่วยได้เมื่อเว็บให้บริการหลายภูมิภาค

เว็บโปรเจกต์โอเพนซอร์ส

โปรเจกต์โอเพนซอร์สอยู่รอดด้วยการมีส่วนร่วมโดยสุจริต แต่หลายโปรเจกต์กลับไม่เผยแพร่ช่องทางติดต่อด้านความปลอดภัยเลย เหลือ GitHub issues เป็นทางเดียว ซึ่งเป็นช่องทางที่แย่มากสำหรับบั๊กร้ายแรงที่ยังไม่แพตช์ security.txt บนเว็บโปรเจกต์พร้อมที่อยู่สำหรับรายงานแบบส่วนตัว บวกนโยบาย disclosure ใน repository ทำให้ maintainer มีโอกาสออกแพตช์ก่อนรายละเอียดจะกลายเป็นสาธารณะ

พอร์ทัลภาครัฐและหน่วยงานสาธารณะ

พอร์ทัลภาครัฐถือข้อมูลอ่อนไหวของประชาชน และเป็นเป้าที่นักวิจัยความปลอดภัยชอบ เพราะหาช่องทางติดต่อที่ชอบด้วยกฎหมายแทบไม่ได้ หลายโปรแกรม CERT ประจำชาติขอให้หน่วยงานเผยแพร่ security.txt อย่างชัดเจน และบางกระบวนการจัดซื้อจัดจ้างก็เริ่มตรวจหาไฟล์นี้แล้ว วันที่ Expires ที่ต่ออายุสม่ำเสมอยังแสดงความเป็นเจ้าของด้านปฏิบัติการต่อความปลอดภัยของพอร์ทัลอีกด้วย

Best Practices

• ชี้ Contact ไปที่กล่องเมลที่มีคนเฝ้าจริง — alias ที่ใช้ร่วมกันอย่าง security@ ซึ่งมีมากกว่าหนึ่งคนคอยดู ดีกว่าที่อยู่ของบุคคลซึ่งหายไปพร้อมการเปลี่ยนงาน ทดสอบด้วยการส่งเมลหาตัวเองจากบัญชีส่วนตัว
• ตั้งวันหมดอายุให้สมจริงแล้วต่ออายุจริง ๆ — หนึ่งปีเป็นค่า default ที่สมเหตุสมผล ใส่ reminder ในปฏิทินล่วงหน้าหนึ่งเดือน ไฟล์ที่หมดอายุบอกนักวิจัยว่าไม่มีใครอยู่บ้าน
• เสิร์ฟไฟล์ผ่าน HTTPS ทั้งสองตำแหน่ง — เผยแพร่ที่ /.well-known/security.txt และ mirror ไว้ที่ /security.txt ด้วย content-type text/plain ไฟล์ที่เปิดผ่าน HTTP อย่างเดียวทำลายความเชื่อมั่นที่ทั้งกลไกนี้พึ่งพา
• ทดสอบ URL จากสาธารณะหลัง deploy — ดึงจากนอกเครือข่ายองค์กร เพราะ proxy กับ DNS ภายในมักโชว์เขียวข้างในแต่ 404 ข้างนอก
• ทำให้หน้า Policy ตรงกับความจริง — ถ้าไฟล์สัญญาว่าตอบภายใน 72 ชั่วโมง แต่กล่องเมลไม่มีคนแตะสามสัปดาห์ คุณแย่กว่าไม่มีไฟล์เสียอีก
• พิจารณาเซ็นด้วย PGP สำหรับโดเมนมูลค่าสูง — ลายเซ็นพิสูจน์ว่า contact ถูกเผยแพร่โดยเจ้าของโดเมน ไม่ใช่ผู้โจมตีที่ยึด subdomain ได้ชั่วคราว

สร้าง security.txt ของคุณวันนี้

รายงานช่องโหว่ที่แพงที่สุดคือรายงานที่ไปไม่ถึงคุณ ตั้งช่องทาง disclosure ให้เสร็จในสิบนาทีข้างหน้า: เปิด Security TXT Generator กรอก contact กับ expiry ของคุณ copy ไฟล์ แล้ว deploy ไปที่ /.well-known/security.txt เมื่อนักวิจัยคนต่อไปเจออะไรตอนตีสอง เขาจะรู้ทันทีว่าต้องเคาะประตูไหน

ขอให้ทุกรายงานส่งถึง inbox ที่ถูกต้อง

คำถามที่พบบ่อย

ถ: ไฟล์ security.txt ควรโฮสต์ไว้ที่ไหนกันแน่?

ตอบ: RFC 9116 ระบุว่าตำแหน่งหลักคือ /.well-known/security.txt ที่ root ของโดเมนคุณ — ไม่ใช่ใน subdirectory ใด ๆ และ RFC ยังอนุญาตให้มีสำเนา fallback ที่ /security.txt การเผยแพร่ทั้งสองที่เพิ่มความเข้ากันได้สูงสุด เพราะเครื่องมือแต่ละตัวเช็ค path ไม่เหมือนกัน และไฟล์ต้องเสิร์ฟผ่าน HTTPS เป็น text/plain

ถ: security.txt มีประโยชน์แค่กับบริษัทใหญ่เท่านั้นหรือ?

ตอบ: ไม่เลย ใครก็ตามที่ดูแลโดเมนได้ประโยชน์ทั้งนั้น ไม่ว่าจะเป็นสตาร์ทอัพ เอเจนซี โปรเจกต์โอเพนซอร์ส เว็บส่วนตัว หรือพอร์ทัลภาครัฐ นักวิจัยไม่ได้ปรับวิธีทำ responsible disclosure ตามขนาดบริษัท — เขามองหาช่องทางติดต่อ และไฟล์นี้คือที่ที่มาตรฐานบอกให้เขามองหา

ถ: ถ้าวันหมดอายุ (Expires) ผ่านไปโดยไม่ต่ออายุ จะเกิดอะไรขึ้น?

ตอบ: ตัวไฟล์ยังถูกเสิร์ฟต่อไป แต่ scanner และนักวิจัยจะถือว่า security.txt ที่หมดอายุเชื่อถือไม่ได้ และบางเครื่องมือก็ flag หรือเมินไปเลย วันหมดอายุมีอยู่เพื่อกันไม่ให้ contact เก่าเก็บรายงานเข้ากลีบเมฆไปตลอดกาล ต่ออายุตามรอบที่ตั้งไว้ ปัญหาก็ไม่เกิดขึ้น

ถ: ใส่ค่า Contact มากกว่าหนึ่งรายการได้ไหม?

ตอบ: ได้ และแนะนำให้ทำด้วย คุณสามารถรวม mailto: address, ฟอร์มเว็บ https: และกล่องเมลอื่น ๆ ไว้ในไฟล์เดียว บรรทัดละ Contact ลำดับไม่ได้หมายถึงความสำคัญ ดังนั้นใส่ทุกช่องทางที่ทีมคุณเฝ้าจริง ๆ

ถ: จำเป็นต้องเซ็นไฟล์ด้วย PGP ไหม?

ตอบ: การเซ็นเป็นเรื่องทางเลือก และมีค่าที่สุดกับโดเมนโปรไฟล์สูงซึ่งผู้โจมตีอาจพยายามเผยแพร่ contact ปลอมหลังยึดระบบได้ สำหรับเว็บส่วนใหญ่ การเสิร์ฟไฟล์ผ่าน HTTPS จากโดเมนของคุณเองก็เพียงพอ แต่ลายเซ็นเพิ่มหลักฐานเชิง cryptography ด้วยต้นทุนที่ต่ำมาก

เครื่องมือที่เกี่ยวข้อง

• Security Headers Generator — ตั้งค่า CSP, HSTS และชุด header ครบตาม OWASP พร้อม export config ที่พร้อมวางสำหรับ web server ยอดนิยม
• CSP Generator — สร้าง Content-Security-Policy ที่แม่นยำเพื่อบล็อกสคริปต์ที่ถูก inject ซึ่งเป็นช่องโหว่ที่นักวิจัยรายงานบ่อยที่สุด
• PII Redactor — ลบชื่อ อีเมล และข้อมูลระบุตัวตนออกจาก log และรายงาน ก่อนแชร์รายละเอียดช่องโหว่ให้บุคคลที่สาม