Security.txt Generator - Tạo Và Kiểm Tra security.txt Theo RFC 9116

Tính năng nổi bật

• Nhập nhiều kênh Contact dạng mailto:, https:// hoặc tel:, tự thêm mailto: khi dán email trần
• Chọn Expires bằng lịch theo giờ máy, ghi ra định dạng RFC 3339 kèm múi giờ, có nút nhanh 3, 6, 11 tháng
• Đủ các trường RFC 9116: Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy, Hiring, cùng trường CSAF
• Tự kiểm tra tệp đang tạo: thiếu trường bắt buộc, Expires ở quá khứ hoặc xa hơn một năm, URL dùng http://
• Trình kiểm tra tệp có sẵn: bắt lỗi tên trường gõ sai và gợi ý tên đúng, trường lặp, mã ngôn ngữ sai, Canonical không khớp URL thật
• Đọc được tệp đã ký OpenPGP dạng cleartext, chấp nhận xuống dòng CRLF hoặc LF
• Lệnh GnuPG mẫu để tự ký tệp trên máy, không yêu cầu dán khóa bí mật lên trang
• Cấu hình mẫu cho Nginx, Apache và thư mục public của Next.js, kèm chuyển hướng từ /security.txt cũ

Vì sao website doanh nghiệp nên có security.txt

Khi một người phát hiện lỗ hổng trên website của bạn, việc khó nhất với họ thường là tìm đúng người để báo. Email chung trên trang liên hệ thường do bộ phận chăm sóc khách hàng đọc, báo cáo kỹ thuật dễ bị bỏ qua hoặc chuyển qua nhiều người trước khi tới đội kỹ thuật. Một số người sẽ bỏ cuộc, số khác có thể công bố lỗ hổng công khai vì không liên lạc được. Security.txt giải quyết đúng vấn đề này bằng một vị trí cố định mà người làm bảo mật đã quen kiểm tra: /.well-known/security.txt. Trong tệp có kênh liên hệ, khóa mã hóa để gửi báo cáo an toàn, chính sách công bố và ngôn ngữ ưu tiên. Tệp chỉ vài dòng, không tốn chi phí vận hành, nhưng cho thấy doanh nghiệp có quy trình tiếp nhận báo cáo bảo mật rõ ràng.

Lợi ích khi sử dụng

• •Người phát hiện lỗ hổng có kênh báo cáo chính thức thay vì phải đoán hoặc công bố ra ngoài
• •Tệp đúng RFC 9116 ngay từ đầu, không mất công sửa sau khi bị công cụ quét báo lỗi
• •Phát hiện sớm tệp đã hết hạn hoặc sai định dạng trên website đang chạy
• •Có sẵn cấu hình máy chủ, không phải tìm cách xử lý thư mục bắt đầu bằng dấu chấm
• •Mọi thứ chạy trong trình duyệt, không có thông tin nào gửi đi

Cách tạo security.txt theo RFC 9116

1. 1Nhập tên miền website để công cụ tự điền Canonical và ví dụ cấu hình máy chủ.
2. 2Điền ít nhất một kênh Contact, mỗi dòng một kênh: email dạng mailto:, trang báo cáo dạng https:// hoặc số điện thoại dạng tel:. Kênh đặt trước được hiểu là kênh ưu tiên.
3. 3Chọn ngày Expires, nên dưới một năm kể từ hôm nay, và đặt lịch nhắc cập nhật trước ngày đó.
4. 4Thêm các trường tùy chọn cần thiết: Encryption trỏ tới khóa công khai OpenPGP, Policy trỏ tới chính sách công bố lỗ hổng, Preferred-Languages như vi, en.
5. 5Xem danh sách kiểm tra bên dưới tệp, sửa hết lỗi, rồi tải security.txt hoặc sao chép nội dung.
6. 6Nếu muốn ký số, chạy lệnh GnuPG trên máy của bạn, sau đó đưa tệp lên máy chủ theo cấu hình mẫu và dán lại nội dung vào tab Kiểm tra để rà lần cuối.

Hai trường bắt buộc: Contact và Expires

RFC 9116 chỉ bắt buộc hai trường. Contact phải xuất hiện ít nhất một lần và là một URI: mailto:bao-mat@congty.vn cho email, https://congty.vn/bao-cao-lo-hong cho trang biểu mẫu, hoặc tel:+84-28-1234-5678 cho điện thoại. Lỗi phổ biến nhất là ghi email trần không có mailto:, hoặc ghi liên kết http:// trong khi chuẩn yêu cầu https://. Có thể khai báo nhiều Contact, thứ tự trong tệp thể hiện thứ tự ưu tiên. Expires phải xuất hiện đúng một lần, ghi theo định dạng ngày giờ RFC 3339 có múi giờ, ví dụ 2027-06-30T23:59:59+07:00 hoặc 2027-06-30T16:59:59Z. Khi quá thời điểm này, tệp được coi là cũ và không nên được tin cậy.

Vì sao Expires nên dưới một năm

Thông tin liên hệ bảo mật thay đổi theo thời gian: người phụ trách nghỉ việc, hộp thư bị đổi, khóa mã hóa hết hạn. Trường Expires buộc doanh nghiệp định kỳ xác nhận lại rằng các kênh trong tệp vẫn còn người đọc. RFC 9116 khuyến nghị giá trị Expires nên cách hiện tại dưới một năm để tránh tệp bị bỏ quên. Công cụ cảnh báo khi Expires xa hơn một năm và báo lỗi khi Expires đã qua. Cách làm thực tế là chọn khoảng 6 đến 11 tháng, đặt lịch nhắc trước ngày hết hạn vài tuần, và mỗi lần gia hạn thì kiểm tra lại toàn bộ kênh liên hệ.

Các trường tùy chọn và cách dùng

Encryption trỏ tới khóa công khai OpenPGP để người báo cáo mã hóa nội dung nhạy cảm; ngoài https://, RFC 9116 còn đưa ví dụ dạng dns: và openpgp4fpr:. Acknowledgments trỏ tới trang ghi nhận những người đã báo lỗi, một cách cảm ơn được giới nghiên cứu đánh giá cao. Policy trỏ tới chính sách công bố lỗ hổng: phạm vi được phép kiểm thử, thời gian phản hồi dự kiến, cam kết không khởi kiện người báo cáo thiện chí. Preferred-Languages liệt kê mã ngôn ngữ như vi, en, chỉ được xuất hiện một lần. Hiring trỏ tới trang tuyển dụng vị trí bảo mật. CSAF là trường do đặc tả OASIS CSAF 2.0 đăng ký, trỏ tới tệp provider-metadata.json dành cho doanh nghiệp phát hành bản tin bảo mật dạng máy đọc được.

Canonical và vì sao phải khớp URL thật

Canonical khai báo URL chính thức của tệp. Theo RFC 9116, nếu tệp có Canonical mà URL dùng để tải tệp không nằm trong danh sách đó, nội dung không nên được tin cậy. Điều này ngăn việc sao chép tệp đã ký của doanh nghiệp khác sang tên miền lạ. Nhầm lẫn hay gặp là khai báo https://congty.vn nhưng tệp thực tế phục vụ ở https://www.congty.vn, hoặc ngược lại. Có thể khai báo nhiều Canonical nếu một tệp dùng cho nhiều tên miền. Ở tab Kiểm tra, nhập URL nơi tệp đang được phục vụ để công cụ đối chiếu với các dòng Canonical.

Ký số tệp bằng OpenPGP

RFC 9116 khuyến nghị ký security.txt bằng chữ ký OpenPGP dạng cleartext, để người đọc xác minh nội dung do chính doanh nghiệp phát hành, không bị sửa đổi trên đường truyền hay trên máy chủ. Việc ký cần khóa bí mật nên công cụ không làm thay bạn: khóa bí mật không bao giờ nên dán vào một trang web. Thay vào đó, công cụ đưa lệnh gpg --clearsign mẫu để chạy trên máy của bạn, rồi gpg --verify để kiểm tra trước khi đưa lên máy chủ. Khi đã ký, nên có trường Canonical, và khóa công khai dùng để ký nên được công bố qua trường Encryption. Mỗi lần sửa tệp hay gia hạn Expires đều phải ký lại.

Đặt tệp lên máy chủ

Vị trí chuẩn là /.well-known/security.txt, phục vụ qua HTTPS với Content-Type text/plain. Có thể đặt thêm ở /security.txt cho công cụ cũ, cách gọn nhất là chuyển hướng 301 về vị trí chuẩn. Với Nginx, nhiều cấu hình có quy tắc chặn mọi đường dẫn bắt đầu bằng dấu chấm để bảo vệ tệp như .env, .git, và quy tắc này vô tình chặn luôn /.well-known; khối location khớp chính xác trong cấu hình mẫu được Nginx ưu tiên hơn quy tắc regex đó. Với Apache, đặt tệp vào thư mục .well-known trong DocumentRoot và ép kiểu text/plain. Với Next.js, đặt tệp vào public/.well-known/security.txt là đủ để phục vụ ở đúng đường dẫn.

Giới hạn của công cụ

Trình kiểm tra đọc nội dung bạn dán vào, không tự tải tệp từ website, nên không kiểm tra được Content-Type, chuyển hướng hay chứng chỉ HTTPS thực tế. Với tệp đã ký, công cụ bóc phần nội dung để kiểm tra nhưng không xác minh chữ ký; hãy dùng gpg --verify. Công cụ kiểm tra cú pháp của URL, không kiểm tra hộp thư hay trang đích có hoạt động không. Cuối cùng, security.txt chỉ là kênh liên hệ: doanh nghiệp vẫn cần người thực sự đọc và xử lý báo cáo trong thời gian đã hứa ở chính sách.

Câu hỏi thường gặp (FAQ)

Từ khóa liên quan

• security.txt
• tạo security.txt
• security.txt generator
• rfc 9116
• .well-known/security.txt
• security.txt example
• security.txt validator
• kiểm tra security.txt
• security.txt expires
• security.txt contact
• security.txt nginx
• security.txt next.js
• vulnerability disclosure policy
• chính sách công bố lỗ hổng
• báo cáo lỗ hổng bảo mật
• responsible disclosure
• ký security.txt pgp
• csaf provider metadata
• bug bounty liên hệ