ITFS Handbook

Appearance

Checklist khi review code auth & sai lầm thường gặp ​

Checklist ​

  1. Authentication và authorization có được tách bạch rõ ràng không, hay việc xác minh token được xem là đã đủ để cấp quyền?
  2. Grant type có phù hợp không? Nếu là Implicit Grant hoặc Password Grant, cần xem lại.
  3. Refresh token có bị lưu trong localStorage không? Nếu có, đây là lỗi cần sửa ngay.
  4. JWT có được kiểm tra đầy đủ signature, audience và issuer, hay chỉ được decode và đọc claim mà không xác thực?
  5. Thời gian sống (TTL) của access token là bao lâu? TTL quá dài mà không có cơ chế thu hồi là một rủi ro.
  6. Có cơ chế refresh token rotation và reuse detection không?
  7. Việc kiểm tra quyền có được thực hiện ở phía server, trên từng endpoint/đối tượng cụ thể theo mô hình rõ ràng (RBAC/ABAC), hay hệ thống tin tưởng user_id/role mà client gửi lên?
  8. Nếu dùng cookie, có cơ chế chống CSRF (thuộc tính SameSite kết hợp CSRF token cho các request thay đổi trạng thái) không?
  9. Mật khẩu có được hash bằng thuật toán đủ mạnh (Argon2id/bcrypt) không, hay lưu plaintext/hash yếu (MD5, SHA-1)?
  10. Endpoint đăng nhập có rate limiting/account lockout để chống brute-force và credential stuffing không?
  11. Session ID có được tạo mới sau khi đăng nhập thành công không (chống session fixation)?

Theo OWASP 2026, Broken Access Control (kiểm soát truy cập bị lỗi) là rủi ro bảo mật được xếp hạng cao nhất — phần lớn xuất phát từ việc bỏ sót mục 7, chứ không phải từ lỗi thuật toán JWT.

Sai lầm thường gặp ​

  • Nhầm lẫn JWT với mã hoá: JWT chỉ được ký (sign), không được mã hoá (encrypt). Phần payload có thể giải mã bằng mắt thường (base64), vì vậy không nên đưa dữ liệu nhạy cảm vào claim.
  • Hệ thống chỉ dùng JWT mà không có cơ chế thu hồi sẽ không thể "đăng xuất ngay lập tức" — phải chờ token hết hạn.
  • Kiểm tra quyền ở phía frontend/mobile mà không lặp lại ở backend: client luôn có thể bị bỏ qua.
  • Không kiểm tra thuật toán ký của JWT (ví dụ chấp nhận alg: none), tạo điều kiện cho kẻ tấn công tự ký token bằng thuật toán yếu hơn.
  • Nhầm ID Token và Access Token: dùng ID Token để gọi API xin dữ liệu (sai mục đích thiết kế) hoặc dùng Access Token để xác định danh tính người dùng (Access Token không đảm bảo chứa thông tin đó).
  • Chỉ lo bảo mật "sau khi đăng nhập" (token, session) mà bỏ quên bảo mật "lúc đăng nhập" — không hash mật khẩu đúng cách, không giới hạn số lần thử sai, không đổi session ID sau khi đăng nhập.
  • Thiết kế phân quyền kiểu "cho phép mọi thứ trừ khi bị cấm" thay vì deny-by-default — dễ lộ endpoint mới thêm vào mà quên gắn quyền.

© rintc