Tweet
Vấn đề xác thực khi sử dụng restful api
🚀 VẤN ĐỀ XÁC THỰC KHI SỬ DỤNG RESTFUL API
🔐 1. Vì sao REST API cần xác thực?
Khi bạn gọi API để thao tác dữ liệu, hệ thống cần biết bạn là ai và có quyền gì. Nếu không có xác thực, bất kỳ ai cũng có thể:
❌ Xóa dữ liệu
❌ Sửa tài khoản
❌ Truy cập thông tin bí mật
➡ Vì vậy, xác thực API chính là “kiểm tra căn cước” trước khi cho phép truy cập.
🔑 2. Ba cách xác thực API phổ biến nhất
File gốc mô tả 3 cơ chế xác thực thường gặp: (1) Basic Authentication – dùng Username + Password
⚠ Nhược điểm lớn:
→ Mật khẩu bị gửi qua lại liên tục trong mỗi request
→ Nếu hacker chặn được traffic → lộ password ngay
(2) API Key – dùng “chìa khóa bí mật” để truy cập
Ví dụ:
GET /users?api_key=abc123
Hoặc:
X-API-Key: abc123
API Key sai → trả về 401 Unauthorized
API Key đúng nhưng không đủ quyền → 403 Forbidden
⚠ Nếu để lộ API Key → hacker có thể phá cả hệ thống
(3) Custom Token (ví dụ: JWT, OAuth, SSO)
Đây là cách hiện đại nhất.
Quy trình:
1️⃣ Người dùng nhập Username + Password
2️⃣ Server xác thực → tạo Token
3️⃣ Token được gửi lại cho Client
4️⃣ Từ đó về sau, Client chỉ cần gửi Token, không cần gửi mật khẩu nữa
5️⃣ Khi Token hết hạn → Login lại
Ưu điểm:
✔ Không truyền password nhiều lần
✔ Tốc độ xử lý nhanh hơn
✔ Tích hợp dễ với SSO (Google login, Facebook login…)
✔ Token có thể chứa luôn quyền truy cập
Nhược điểm:
⚠ Phức tạp hơn trong quản lý token
⚠ Nếu máy chủ xác thực bị tấn công → rủi ro cao
⚙ 3. QUẢN LÝ KEY VÀ THÔNG TIN NHẠY CẢM – TUYỆT ĐỐI KHÔNG HARD-CODE!
Tài liệu cảnh báo rõ:
❌ KHÔNG BAO GIỜ đặt API Key, Username, Password trực tiếp vào code
Ví dụ bên dưới là SAI hoàn toàn:
API_KEY = "abc123"
Lý do:
➡ Cách đúng là Softcoding:
🛡 4. Logging sai cách cũng làm lộ dữ liệu!
Ví dụ xấu:
POST /api/login?username=admin&password=123456
👉 Dù bạn dùng HTTPS, tham số vẫn lưu trong:
➡ Luôn gửi thông tin bảo mật trong BODY request, không đưa lên URL
🔐 5. Mã hóa dữ liệu ở trạng thái lưu trữ (Data at Rest)
Ngay cả khi hacker đã lấy được file, họ vẫn không đọc được nếu file được mã hóa.
Có 3 phương pháp chính: 1️⃣ Mã hóa toàn bộ ổ đĩa
→ Dùng BitLocker, TPM, OS encryption… 2️⃣ Mã hóa hệ thống File
→ Chỉ mã hóa thư mục chứa thông tin nhạy cảm 3️⃣ Mã hóa ở tầng Database
→ Ví dụ: Tự mã hóa cột “số thẻ ngân hàng”
➡ KẾT LUẬN:
Bạn phải mã hóa cả khi dữ liệu đang truyền và đang lưu, nếu không hacker sẽ đọc được dữ liệu thật.
🔐 1. Vì sao REST API cần xác thực?
Khi bạn gọi API để thao tác dữ liệu, hệ thống cần biết bạn là ai và có quyền gì. Nếu không có xác thực, bất kỳ ai cũng có thể:
❌ Xóa dữ liệu
❌ Sửa tài khoản
❌ Truy cập thông tin bí mật
➡ Vì vậy, xác thực API chính là “kiểm tra căn cước” trước khi cho phép truy cập.
🔑 2. Ba cách xác thực API phổ biến nhất
File gốc mô tả 3 cơ chế xác thực thường gặp: (1) Basic Authentication – dùng Username + Password
- Client gửi username & password kèm request
- Dữ liệu được encode Base64, nhưng KHÔNG MÃ HÓA
- Nếu không dùng HTTPS ⇒ rất dễ bị nghe lén
- Vì vậy Basic Auth luôn phải đi kèm SSL/TLS
⚠ Nhược điểm lớn:
→ Mật khẩu bị gửi qua lại liên tục trong mỗi request
→ Nếu hacker chặn được traffic → lộ password ngay
(2) API Key – dùng “chìa khóa bí mật” để truy cập
- API Key là một chuỗi ký tự giống như mật khẩu
- Ai có key → có quyền gọi API
- Thường được đặt trong:
- Query string
- HTTP Header
- Cookie
Ví dụ:
GET /users?api_key=abc123
Hoặc:
X-API-Key: abc123
API Key sai → trả về 401 Unauthorized
API Key đúng nhưng không đủ quyền → 403 Forbidden
⚠ Nếu để lộ API Key → hacker có thể phá cả hệ thống
(3) Custom Token (ví dụ: JWT, OAuth, SSO)
Đây là cách hiện đại nhất.
Quy trình:
1️⃣ Người dùng nhập Username + Password
2️⃣ Server xác thực → tạo Token
3️⃣ Token được gửi lại cho Client
4️⃣ Từ đó về sau, Client chỉ cần gửi Token, không cần gửi mật khẩu nữa
5️⃣ Khi Token hết hạn → Login lại
Ưu điểm:
✔ Không truyền password nhiều lần
✔ Tốc độ xử lý nhanh hơn
✔ Tích hợp dễ với SSO (Google login, Facebook login…)
✔ Token có thể chứa luôn quyền truy cập
Nhược điểm:
⚠ Phức tạp hơn trong quản lý token
⚠ Nếu máy chủ xác thực bị tấn công → rủi ro cao
⚙ 3. QUẢN LÝ KEY VÀ THÔNG TIN NHẠY CẢM – TUYỆT ĐỐI KHÔNG HARD-CODE!
Tài liệu cảnh báo rõ:
❌ KHÔNG BAO GIỜ đặt API Key, Username, Password trực tiếp vào code
Ví dụ bên dưới là SAI hoàn toàn:
API_KEY = "abc123"
Lý do:
- Dễ bị lộ khi chia sẻ source
- Khó bảo trì, đổi key phải sửa code
- Không thể dùng cho nhiều môi trường (Dev, Test, Prod)
➡ Cách đúng là Softcoding:
- Lưu key vào file config
- Load bằng thư viện (ví dụ configparser trong Python)
- Không commit file chứa key lên Git
🛡 4. Logging sai cách cũng làm lộ dữ liệu!
Ví dụ xấu:
POST /api/login?username=admin&password=123456
👉 Dù bạn dùng HTTPS, tham số vẫn lưu trong:
- History trình duyệt
- Server logs
- Bookmark
➡ Luôn gửi thông tin bảo mật trong BODY request, không đưa lên URL
🔐 5. Mã hóa dữ liệu ở trạng thái lưu trữ (Data at Rest)
Ngay cả khi hacker đã lấy được file, họ vẫn không đọc được nếu file được mã hóa.
Có 3 phương pháp chính: 1️⃣ Mã hóa toàn bộ ổ đĩa
→ Dùng BitLocker, TPM, OS encryption… 2️⃣ Mã hóa hệ thống File
→ Chỉ mã hóa thư mục chứa thông tin nhạy cảm 3️⃣ Mã hóa ở tầng Database
→ Ví dụ: Tự mã hóa cột “số thẻ ngân hàng”
➡ KẾT LUẬN:
Bạn phải mã hóa cả khi dữ liệu đang truyền và đang lưu, nếu không hacker sẽ đọc được dữ liệu thật.