Nhầm đăng nhập với phân quyền
Đăng nhập xác minh danh tính, còn phân quyền xác định danh tính đó có được thực hiện hành động đang yêu cầu hay không. Một người đã đăng nhập không mặc nhiên được xem, sửa hoặc xóa mọi tài nguyên mà hệ thống có thể truy cập. Lỗi thường gặp là chỉ kiểm tra phiên đăng nhập rồi tin rằng việc ẩn nút trên giao diện đã đủ ngăn thao tác trái phép. [1]
Gợi ý: mô tả quyền theo bộ ba người dùng, tài nguyên và hành động. Với từng màn hình hoặc quy trình, cần đối chiếu cả thao tác đọc, tạo, sửa, xóa, phê duyệt và xuất dữ liệu. Ma trận này nên được lập trước khi chọn thư viện phân quyền để yêu cầu nghiệp vụ không bị giới hạn bởi cấu hình sẵn có của công cụ.
Cấp quyền rộng để xử lý nhanh
Cấp toàn bộ quyền cho một phòng ban giúp triển khai ban đầu nhanh hơn nhưng làm tăng phạm vi ảnh hưởng khi tài khoản bị dùng sai. Nguyên tắc quyền tối thiểu yêu cầu mỗi người chỉ có quyền cần thiết cho công việc, xét cả chiều dọc giữa cấp quản lý và nhân viên lẫn chiều ngang giữa các bộ phận cùng cấp. [1]
Gợi ý: đặt trạng thái mặc định là từ chối và yêu cầu mỗi quyền được cấp có lý do cụ thể. Quy trình điều chuyển, nghỉ việc hoặc kiêm nhiệm cũng cần điểm kiểm tra để tránh quyền cũ tích lũy theo thời gian. Việc rà soát định kỳ giúp phát hiện chênh lệch giữa quyền đang tồn tại và thiết kế đã được phê duyệt, nhưng không thay thế kiểm soát trên từng yêu cầu.
Chỉ kiểm tra quyền ở giao diện
Ẩn nút, khóa trường nhập hoặc chặn đường dẫn trên trình duyệt chỉ cải thiện trải nghiệm; người dùng vẫn có thể gửi yêu cầu trực tiếp đến API. OWASP khuyến nghị kiểm tra quyền ở mọi yêu cầu và đặc biệt lưu ý các hàm truy cập nguồn dữ liệu bằng mã đối tượng do người dùng cung cấp. Kiểm tra phải bao phủ cả đối tượng, thuộc tính và chức năng quản trị. [1][2]
Ví dụ: nhân viên được mở hóa đơn số 125 không có nghĩa họ được mở hóa đơn 126 bằng cách thay mã trên URL. Gợi ý: phía máy chủ nên xác minh hóa đơn thuộc đúng đơn vị, khách hàng hoặc phạm vi phụ trách của người yêu cầu; đồng thời chỉ trả về những trường dữ liệu mà người đó được phép xem.
Dùng vai trò cho mọi tình huống
RBAC gắn quyền với vai trò và phù hợp khi quy tắc tương đối ổn định. Tuy nhiên, việc tạo thêm vai trò cho từng chi nhánh, dự án, trạng thái hồ sơ hoặc quan hệ sở hữu có thể khiến mô hình khó kiểm thử. ABAC dùng thuộc tính của người dùng, tài nguyên và môi trường; ReBAC quyết định theo quan hệ, chẳng hạn người tạo nội dung được sửa nội dung đó. [1]
Gợi ý: không cần thay toàn bộ RBAC nếu hệ thống hiện tại còn đơn giản. Có thể giữ vai trò cho quyền chức năng tổng quát, sau đó bổ sung điều kiện theo phạm vi dữ liệu hoặc quan hệ sở hữu. Trước khi phát triển, đội dự án nên viết các quyết định quyền thành câu có thể kiểm thử, gồm cả trường hợp được phép và bị từ chối.
Thiếu kiểm thử và dấu vết vận hành
Một điểm kiểm tra bị bỏ sót có thể làm lộ hoặc cho phép sửa tài nguyên được bảo vệ. Cấu hình mặc định của framework cũng có thể thay đổi hoặc không đáp ứng yêu cầu riêng của ứng dụng. Ngoài kiểm thử các trường hợp hợp lệ, cần kiểm thử yêu cầu sai vai trò, sai chủ sở hữu, sai tổ chức, trường dữ liệu bị cấm và endpoint cũ còn hoạt động. [1][2]
Gợi ý: quản lý danh mục API, phiên bản đang triển khai và các endpoint thử nghiệm; ghi nhận quyết định cho phép hoặc từ chối ở mức đủ phục vụ điều tra, nhưng tránh đưa dữ liệu nhạy cảm vào nhật ký. Cảnh báo và lớp kiểm soát bổ sung giúp giảm rủi ro, song không nên được mô tả như bảo đảm hệ thống an toàn tuyệt đối.