Lỗ hổng bảo mật số một theo OWASP là gì, và bạn phòng nó ở đâu trong kiến trúc?

Cách làm bền vững nhất là khiến việc truy vấn KHÔNG có phạm vi trở nên khó viết. Ví dụ mọi hàm truy cập nhận actor làm tham số bắt buộc và tự thêm điều kiện WHERE owner_id = actor.id; hoặc dùng row-level security ở database, để cả những đường đi mà bạn quên vẫn bị chặn. Điểm chung là phòng thủ nằm ở nơi không thể bỏ qua, chứ không phải nơi cần nhớ.

Một dạng khác hay bị bỏ sót là phân quyền theo THAO TÁC chứ không theo tài nguyên: người dùng xem được đơn hàng của mình là đúng, nhưng họ có được HUỶ nó sau khi đã giao không? Có được đổi trường status qua API cập nhật chung không? Rất nhiều lỗ hổng nằm ở chỗ endpoint cập nhật nhận cả object và ghi đè những trường mà người dùng lẽ ra không được chạm — mass assignment. Cách chặn là danh sách trường cho phép, không phải danh sách trường cấm.

Về kiểm tra, đây là loại lỗ hổng mà quét tự động gần như vô dụng: công cụ không biết đơn hàng 1234 thuộc về ai. Nên nó phải được kiểm bằng test có chủ đích — với mỗi endpoint, một test dùng danh tính của người dùng B để truy cập tài nguyên của người dùng A và mong đợi 404. Viết một helper cho việc đó rồi áp cho mọi endpoint là cách rẻ nhất để biến một loại lỗ hổng thành một checklist.