Authentication và authorization: QA nên kiểm quyền truy cập thế nào
Nhiều lỗi bảo mật nghiêm trọng bắt đầu từ nhầm lẫn đơn giản: hệ thống biết bạn là ai, nhưng quên kiểm object có thuộc về bạn không.
- Không token: 401
- Token sai: 401
- Đúng user, sai role: 403 hoặc không có action
- Đúng role, sai object: 403 hoặc 404
Authentication trả lời “bạn là ai?”
Authentication là login, password, token, session và expiry. Nó chứng minh danh tính nhưng không quyết định bạn được xem gì.
Hãy kiểm thông tin đúng, password sai, email viết hoa, thiếu token, token hết hạn và logout.
Authorization trả lời “bạn được làm gì?”
Authorization kiểm role và quyền sở hữu object. User đã login vẫn không được mở đơn hàng hay tài khoản của người khác.
API hay lỗi ở đây vì id dễ đoán, còn nút ẩn trên frontend không bảo vệ backend.
Kiểm quyền sở hữu object
Dùng hai user. Mở object bằng owner, ghi id, rồi gọi id đó bằng token user thứ hai. Thường expected là 403 hoặc 404.
Vì sao đôi khi 404 tốt hơn
Với object riêng tư, 404 che luôn việc object có tồn tại hay không. 403 cho biết nó tồn tại nhưng bạn không được xem.
Kiểm role
Role phải kiểm cả UI lẫn API. Nếu nút admin bị ẩn, vẫn gửi request bằng token user thường.
Nút ẩn là tiện ích. Request bị từ chối mới là bảo mật.
Access bug thường gặp
Thiếu filter owner, chỉ kiểm role ở frontend, token vẫn dùng được sau logout, endpoint lộ khác biệt giữa object riêng tư tồn tại và không tồn tại.
Bug report về access cần hai account, ngữ cảnh token và object id.
Matrix actor × action × object
Danh sách role là chưa đủ. Tạo row như manager A đọc client A, manager A sửa client B, user thường gọi admin endpoint, nhân viên cũ dùng token cũ. Mỗi row cần expected allow, deny hoặc hide.
Đừng chỉ test GET. BOLA có thể đã chặn read nhưng còn trong PATCH, DELETE, bulk endpoint, export hoặc id lồng trong body. UUID khó đoán hơn nhưng không thay permission check phía server.
Actor Action Object Expected\nmanager A GET client A 200\nmanager A GET client B 403/404 theo contract\nmanager A PATCH client B 403/404, data không đổi\nviewer DELETE client A 403\nno token GET client A 401 + WWW-Authenticate
Vòng đời session và token
Kiểm issue, rotation sau login hoặc đổi quyền, expiry, refresh, logout, revoke, đổi password và nhiều thiết bị. Một số architecture cho access token cũ sống tới expiry ngắn; khi đó logout phải revoke refresh và UI không được hứa hơn server.
- Session id đổi sau login để ngăn session fixation.
- Cookie có Secure, HttpOnly, SameSite phù hợp; token không lộ trong URL hoặc log.
- Token hết hạn, hỏng hoặc ký sai key bị từ chối.
- Thay đổi role đến permission check trong thời gian đã thống nhất dù có cache.
- Refresh reuse, logout và đổi password theo policy đã document.
BOLA, BFLA và quyền trên field
BOLA là user được gọi function nhưng backend không kiểm object id cụ thể. BFLA là role không được gọi function, ví dụ manager gọi admin export. Lỗi property-level làm lộ hoặc nhận field mà role không được dùng.
Trong CRM, hãy test client id của người khác, admin-only bulk export và PATCH có owner_id hoặc is_vip mà form không hiển thị. Ẩn button không xử lý các risk phía server này.
Câu hỏi thường gặp về access
Object riêng tư của user khác nên trả 403 hay 404?
Cả hai có thể đúng theo contract. 404 giấu việc object tồn tại, 403 nói rõ bị từ chối. Điều bắt buộc là nhất quán, không lộ data và không thực hiện action.
UUID có ngăn BOLA không?
Không. UUID giảm khả năng đoán nhưng id có thể lộ qua link, log, export hoặc response. Server vẫn phải kiểm authorization cho từng object.
Kiểm role qua UI đã đủ chưa?
Chưa. Control bị ẩn chỉ cải thiện UX; request vẫn gửi trực tiếp được. Server phải authorize mọi method và object.
Kiểm access ít bước nhưng tác động lớn: đôi khi chỉ đổi một id là thấy backend có bảo vệ dữ liệu thật hay không.