Lưu Access Token Ở Đâu? Được nhưng chưa đủ

Access Token là một phần quan trọng trong bảo mật API, giúp xác thực và phân quyền người dùng. Tuy nhiên, nếu lưu trữ Access Token không đúng cách, ứng dụng có thể bị tấn công, gây rò rỉ dữ liệu. Trong bài viết này, chúng ta sẽ tìm hiểu các cách phổ biến để lưu trữ Access Token, phân tích ưu nhược điểm của từng phương pháp và đề xuất giải pháp tốt nhất để bảo vệ thông tin người dùng.

Các phương pháp lưu trữ Access Token phổ biến

1. Lưu trong Local Storage

Access Token được lưu trữ trong localStorage, có thể truy cập từ JavaScript trên trình duyệt.
Khi cần sử dụng, ứng dụng sẽ lấy token từ localStorage và gửi trong các yêu cầu HTTP. Ưu điểm:
Dễ triển khai và truy xuất từ bất kỳ trang nào trong ứng dụng.
Token tồn tại sau khi reload trang hoặc đóng/mở lại trình duyệt. Nhược điểm:
Dễ bị tấn công XSS (Cross-Site Scripting): Nếu một kẻ tấn công chèn được mã độc vào ứng dụng (ví dụ qua form nhập liệu hoặc tập lệnh bên ngoài), họ có thể truy cập localStorage và đánh cắp token.
Không thể tự động gửi token trong mỗi request như Cookie.
Không bảo vệ khỏi các cuộc tấn công CSRF. Khi nào nên dùng? Không khuyến nghị sử dụng Local Storage để lưu Access Token trong các ứng dụng yêu cầu bảo mật cao.

Nguồn: Internet

2. Lưu trong Session Storage

Token được lưu trong sessionStorage, chỉ tồn tại trong phiên làm việc của trình duyệt. Ưu điểm:

Ít rủi ro hơn so với localStorage vì token bị xóa khi người dùng đóng trình duyệt.
Hạn chế được phần nào nguy cơ XSS nếu kết hợp với cơ chế bảo vệ tốt. Nhược điểm:
Vẫn có thể bị tấn công XSS nếu ứng dụng không bảo vệ đúng cách.
Token bị mất khi người dùng reload trang. Khi nào nên dùng? Có thể phù hợp với các ứng dụng có yêu cầu bảo mật trung bình nhưng không phải là giải pháp tốt nhất.

3. Lưu trong Cookie (HttpOnly, Secure)

Access Token được lưu trong cookie với flag HttpOnly, Secure, SameSite để bảo vệ khỏi các cuộc tấn công phổ biến.
Trình duyệt sẽ tự động gửi token trong mỗi request đến server.

Ưu điểm:

Bảo vệ tốt hơn khỏi XSS vì JavaScript không thể truy cập cookie HttpOnly.
Khi kết hợp với SameSite=Strict hoặc Lax, có thể giảm thiểu nguy cơ CSRF.
Cookie có thể được cấu hình để chỉ gửi qua HTTPS, tăng cường bảo mật.

Nhược điểm:

Có thể bị tấn công CSRF nếu không thiết lập SameSite đúng cách.
Phải quản lý thời gian hết hạn của cookie một cách hợp lý.

Khi nào nên dùng?

Rất phù hợp với các ứng dụng yêu cầu bảo mật cao.

Nguồn: Internet

4. Lưu trong Memory (RAM)

Lưu trữ token trong biến JavaScript, thường là trong state của ứng dụng (ví dụ: React Context, Vuex, Redux, Pinia).