Có người báo lỗ hổng cho bạn: security.txt và cách trả lời

Một người dùng app của bạn tò mò mở DevTools, thấy API trả về cả số điện thoại của người khác. Họ muốn báo cho bạn. Họ vào trang web, không thấy email liên hệ nào ngoài form “Góp ý”. Nhắn fanpage thì ba ngày chưa ai trả lời. Đến lúc đó họ có ba lựa chọn: bỏ qua, đăng lên group cho mọi người biết, hoặc tệ hơn, kể cho người không tử tế.

Robot linh vật bên hòm thư có khiên nhỏ, lá thư phát sáng đang được bỏ vào

Bạn không kiểm soát được việc người khác tìm ra lỗi. Bạn kiểm soát được việc họ báo cho ai, và bạn trả lời thế nào.

security.txt: một file, năm phút

RFC 9116 định nghĩa một file văn bản đặt ở https://ten-mien/.well-known/security.txt, nói cho người tìm ra lỗi biết cách liên hệ. Hai trường bắt buộc là Contact (ít nhất một) và Expires (đúng một). RFC khuyên đặt Expires không quá một năm, để file không bị bỏ quên với thông tin cũ.

Contact: mailto:security@app-cua-ban.com
Contact: https://app-cua-ban.com/bao-lo-hong
Expires: 2027-10-01T00:00:00.000Z
Preferred-Languages: vi, en
Policy: https://app-cua-ban.com/bao-lo-hong
Acknowledgments: https://app-cua-ban.com/cam-on
Canonical: https://app-cua-ban.com/.well-known/security.txt

Các trường còn lại là tùy chọn: Encryption (khóa PGP nếu bạn muốn nhận báo mã hóa), Policy, Acknowledgments, Preferred-Languages, Canonical, Hiring. File phải phục vụ qua HTTPS, kiểu text/plain với UTF-8. Chữ ký OpenPGP được khuyên dùng nhưng không bắt buộc.

Cách đặt file:

Next.js: tạo public/.well-known/security.txt.
Astro, Vite, trang tĩnh: cũng thư mục public/.
Nginx: location = /.well-known/security.txt { alias /var/www/security.txt; default_type text/plain; }
App nhiều tên miền (app., api., admin.): mỗi tên miền một file, hoặc trỏ Canonical về một chỗ.

Đặt nhắc lịch trước ngày Expires một tháng để cập nhật. File hết hạn trông như một dự án bị bỏ hoang.

Hộp thư nhận báo

Tạo security@ riêng, chuyển tiếp cho ít nhất hai người. Một người đi nghỉ thì người kia vẫn thấy.
Kiểm tra bộ lọc thư rác. Báo cáo lỗ hổng thường có đường link lạ, đoạn code, tệp đính kèm, đúng những thứ bộ lọc hay chặn.
Với dự án mã nguồn mở trên GitHub, bật Private vulnerability reporting trong phần Security của repo để người báo không phải mở issue công khai.

Trang chính sách: viết ngắn, viết rõ

Trang Policy không cần dài. OWASP gợi ý những điểm sau, và với app nhỏ thì vài đoạn là đủ:

Phạm vi: tên miền, app nào được thử. Hệ thống của bên thứ ba (Supabase, Stripe, Vercel) không thuộc phạm vi, báo cho họ.
Điều không được làm: không truy cập, sửa, xóa dữ liệu của người khác quá mức cần để chứng minh lỗi; không DDoS; không lừa đảo nhân viên.
Cam kết của bạn: phản hồi trong bao lâu, sẽ cập nhật tiến độ, và không có ý định khởi kiện người báo cáo thiện chí làm đúng chính sách. OWASP khuyên không đe dọa pháp lý người báo, và nên hỏi ý kiến luật sư khi viết phần cam kết này.
Cảm ơn: ghi tên trên trang cảm ơn nếu người báo đồng ý. Có thưởng tiền hay không thì nói rõ.

Khi nhận được báo cáo

Một quy trình đủ dùng cho team nhỏ:

Trả lời trong 1 đến 2 ngày làm việc, kể cả chỉ để nói “đã nhận, đang xem”. Đây là bước quan trọng nhất. Người báo im lặng chờ lâu là lý do số một khiến họ công khai sớm.
Xác minh: tái hiện lỗi trên môi trường của bạn. Không tái hiện được thì hỏi thêm, đừng đóng ngay.
Đánh giá mức độ: lộ dữ liệu người khác, chiếm tài khoản, chạy lệnh trên server là nghiêm trọng; thiếu một header là thấp.
Sửa, rồi báo lại cho người báo thử lại nếu họ muốn.
Kiểm xem đã có ai khai thác chưa: xem log quanh endpoint bị lỗi. Nếu dữ liệu cá nhân đã bị lộ, nghĩa vụ thông báo cho cơ quan chức năng có thể đã bắt đầu tính giờ.
Công bố và cảm ơn: một ghi chú trong changelog hay trang bảo mật, có tên người báo nếu họ muốn.

Về thời gian sửa, OWASP nêu mốc 90 ngày là chuẩn phổ biến, ví dụ chính sách của Project Zero (Google) cho bên bị báo 90 ngày để vá, lỗi đang bị khai thác thì hạn ngắn hơn. Với app web tự làm, lỗi lộ dữ liệu thường nên sửa trong vài ngày, không phải vài tháng.

Báo cáo thật và email đòi tiền

Có một kiểu email gửi hàng loạt: “Tôi tìm thấy lỗ hổng nghiêm trọng trên trang của bạn, bạn có chương trình bug bounty không?”, kèm ảnh chụp kết quả quét tự động cho thấy thiếu một header hay bản ghi DMARC. Người ta hay gọi là “beg bounty”.

Cách phân biệt: báo cáo thật nói cụ thể endpoint nào, các bước tái hiện, dữ liệu gì bị lộ. Email đòi tiền chung chung và hỏi về tiền trước khi nói lỗi gì. Cả hai trường hợp, trả lời lịch sự, cảm ơn, và làm đúng chính sách bạn đã công bố. Thiếu header thì vẫn nên thêm, chỉ là không cần trả tiền.

Đừng trả tiền để người lạ “không công bố”. Đó không còn là báo lỗi.

Khi nào nên thuê đánh giá độc lập

security.txt giúp bạn nhận được lỗi người khác tình cờ thấy. Nó không thay được việc chủ động tìm. Nên cân nhắc thuê một bên đánh giá (pentest) khi:

app bắt đầu giữ dữ liệu nhạy cảm: sức khỏe, tài chính, giấy tờ tùy thân, vị trí;
có khách hàng doanh nghiệp yêu cầu báo cáo bảo mật trước khi ký hợp đồng;
sắp ra mắt chức năng lớn như thanh toán, nhiều tổ chức trong một app, API mở cho bên ngoài;
đã sửa một lỗi nghiêm trọng và muốn chắc không còn lỗi cùng loại.

Trước khi thuê, tự làm một vòng: chạy các bước “kiểm tra app của bạn” trong các bài trên blog này cho phân quyền, đăng nhập, upload, webhook. Bên đánh giá sẽ dùng thời gian của họ cho những thứ khó hơn.

Kiểm tra app của bạn trong vài phút

Mở https://ten-mien-cua-ban/.well-known/security.txt. Ra 404 là chưa có.
Tạo file theo mẫu ở trên, deploy, mở lại kiểm tra header Content-Type: text/plain.
Gửi thử một email tới security@ từ một địa chỉ ngoài, xem nó đến tay ai, có vào thư rác không.
Viết trang chính sách ngắn, gắn link vào trường Policy.
Đặt nhắc lịch cập nhật Expires.

App của bạn đã từng nhận được báo cáo lỗ hổng nào chưa, và bạn trả lời ra sao? Vào cộng đồng Vibe Code & Bảo Mật kể cho mọi người nghe nhé.

Nguồn

RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, IETF
Vulnerability Disclosure Cheat Sheet, OWASP
Privately reporting a security vulnerability, GitHub Docs