4 lớp bảo mật API giúp hệ thống chống hacker

Bốn lớp bảo mật API nền tảng gồm Input Validation, Rate Limiting, Authentication và Authorization. Mỗi lớp xử lý một kiểu rủi ro khác nhau, cùng tạo thành chuỗi phòng thủ cho backend.

1. Input Validation: Không tin dữ liệu gửi từ frontend

Input Validation là bước kiểm tra xem dữ liệu gửi vào API có hợp lệ hay không. Một sai lầm phổ biến là chỉ kiểm tra ở frontend, chẳng hạn yêu cầu người dùng nhập đủ tên, email và mật khẩu trên form đăng ký, nhưng backend lại lưu dữ liệu thẳng vào database mà không kiểm tra lại.

Vấn đề là frontend không phải rào chắn bảo mật. Kẻ tấn công có thể gọi trực tiếp API bằng công cụ như Postman, bỏ qua hoàn toàn các cảnh báo và quy tắc trên giao diện. Nếu API đăng ký nhận dữ liệu thiếu trường nhưng vẫn ghi vào database, hệ thống sẽ nhanh chóng có dữ liệu không nhất quán.

1.1. Thiết lập quy tắc kiểm tra ở backend

1. Xác định trường bắt buộc.
   • Với API đăng ký, các trường cơ bản gồm name, email và password.
   • Mỗi trường cần có quy tắc riêng thay vì chỉ kiểm tra chung chung.
2. Kiểm tra định dạng và độ dài dữ liệu.
   • Email cần đúng định dạng email.
   • Password nên có độ dài tối thiểu phù hợp với chính sách bảo mật của hệ thống.
3. Chặn request lỗi trước logic nghiệp vụ.
   • Middleware validation chạy trước khi API thực hiện thao tác lưu dữ liệu.
   • Nếu có lỗi, backend trả phản hồi lỗi ngay và không tiếp tục xử lý logic chính.

Trong Express, bạn có thể dùng Express Validator để tạo các quy tắc kiểm tra dữ liệu trong body của request. Middleware này chạy các quy tắc, lưu lỗi vào request, sau đó API dùng validationResult để kiểm tra lỗi. Khi có lỗi, API dừng lại và trả phản hồi phù hợp thay vì ghi dữ liệu vào database.

1.2. Sanitize dữ liệu để giảm nguy cơ XSS

Validation chưa đủ nếu dữ liệu chứa mã độc. Một người dùng có thể nhập đoạn mã tấn công XSS vào trường name. Nếu giá trị này được lưu nguyên vẹn và hiển thị lại trên website, mã độc có thể được thực thi trong trình duyệt.

Express Validator hỗ trợ sanitize, tức làm sạch dữ liệu. Với phương thức escape, các ký tự có khả năng gây nguy hiểm được chuyển sang dạng an toàn hơn trước khi lưu. Đây là lý do nguyên tắc quan trọng nhất của lớp này là: đừng tin dữ liệu từ frontend, luôn xác thực và làm sạch dữ liệu tại backend.

2. Rate Limiting: Giới hạn tần suất gọi API

API đăng nhập thường là mục tiêu của tấn công brute force. Kẻ tấn công có thể dùng script gửi hàng nghìn hoặc hàng triệu request, thử liên tục các cặp email và mật khẩu để tìm thông tin đăng nhập đúng.

Không chỉ API login, nhiều endpoint khác cũng có thể bị gọi dồn dập để làm cạn tài nguyên máy chủ. Khi đó, người dùng hợp lệ có thể gặp tình trạng hệ thống chậm hoặc không thể sử dụng dịch vụ.

2.1. Cách Rate Limiting bảo vệ hệ thống

1. Đặt mức request tối đa theo địa chỉ IP.
   • Ví dụ, một IP chỉ được gửi tối đa năm request trong vòng 15 phút cho API login.
   • Vượt quá giới hạn, các request tiếp theo bị chặn.
2. Áp dụng giới hạn cho endpoint nhạy cảm.
   • API đăng nhập là ưu tiên đầu tiên vì thường bị dò mật khẩu.
   • Bạn cũng cần cân nhắc các API có nguy cơ bị lạm dụng hoặc tiêu tốn nhiều tài nguyên.
3. Tách logic giới hạn thành middleware.
   • Middleware giúp bạn áp dụng nhất quán và dễ bảo trì.
   • Trong Express, Express Rate Limit hỗ trợ tạo middleware giới hạn request.

Với Express Rate Limit, thuộc tính max định nghĩa số request tối đa và windowMs định nghĩa khung thời gian tính bằng mili giây. Khi middleware được gắn vào API login, hệ thống chỉ xử lý các request trong mức cho phép. Sau đó, request bị chặn để giảm khả năng brute force và tránh máy chủ quá tải.

Rate Limiting không phải tính năng phụ. Đây là tuyến phòng thủ cơ bản để giảm tác động từ tấn công brute force và các đợt request dồn dập có thể làm ảnh hưởng đến hiệu năng dịch vụ.

3. Authentication: Xác minh người gọi API là ai

Nhiều API không thể công khai, đặc biệt là API trả về thông tin cá nhân, lịch sử đơn hàng hoặc dữ liệu tài khoản. Authentication giúp hệ thống xác minh người gửi request đã đăng nhập và có danh tính hợp lệ hay chưa.

Có nhiều cách triển khai Authentication như session, OAuth 2.0 và JSON Web Token. Với JSON Web Token, sau khi người dùng đăng nhập thành công, hệ thống tạo một token rồi gửi về frontend. Các request đến API được bảo vệ phải mang token này trong header.

3.1. Luồng xác thực bằng JSON Web Token

1. Tạo token sau khi đăng nhập thành công.
   • Token chỉ nên chứa thông tin cần thiết như ID và quyền của người dùng.
   • Không đưa mật khẩu, số căn cước hoặc dữ liệu nhạy cảm vào token.
2. Lưu chữ ký bí mật trong biến môi trường.
   • Chữ ký bí mật được dùng để ký và xác minh token.
   • Không nên viết trực tiếp giá trị này trong mã nguồn.
3. Đặt thời gian hết hạn cho token.
   • Ví dụ minh họa sử dụng thời hạn một giờ.
   • Token có thời hạn giúp giảm rủi ro nếu token bị lộ.
4. Xác minh token trước khi vào API bảo vệ.
   • Middleware lấy token từ header của request.
   • Nếu token hợp lệ, thông tin người dùng được gắn vào request để logic API sử dụng.

Middleware Authenticate Token cần xử lý rõ hai trường hợp. Nếu không có token hoặc token không hợp lệ, hệ thống trả lỗi và dừng ngay. Nếu token hợp lệ, middleware gọi next để API tiếp tục xử lý và chỉ trả dữ liệu phù hợp với người dùng hiện tại.

4. Authorization: Phân quyền sau khi đã đăng nhập

Authentication trả lời câu hỏi: người dùng này là ai? Authorization trả lời câu hỏi tiếp theo: người dùng này được phép làm gì?

Ví dụ, API xóa sản phẩm có thể yêu cầu đăng nhập. Nhưng nếu chỉ có Authentication, mọi tài khoản đã đăng nhập đều có thể gọi API xóa sản phẩm. Đây là rủi ro lớn vì người dùng thông thường không nên có quyền như quản trị viên.

4.1. Kiểm tra quyền trước các thao tác nhạy cảm

1. Xác thực danh tính trước.
   • Middleware Authenticate Token kiểm tra token để chắc chắn request đến từ người dùng đã đăng nhập.
   • Thông tin quyền của người dùng được lấy từ token đã xác minh.
2. So sánh quyền hiện tại với quyền yêu cầu.
   • Middleware authorize nhận vai trò cần thiết, chẳng hạn admin.
   • Nếu vai trò không khớp, hệ thống trả lỗi và không chạy logic API.
3. Chỉ cho phép đúng vai trò đi tiếp.
   • Tài khoản admin có thể thực hiện thao tác xóa sản phẩm.
   • Tài khoản người dùng thông thường bị chặn dù đã đăng nhập hợp lệ.

Authorization có thể áp dụng cho nhiều vai trò tùy bối cảnh như admin, giám đốc, kế toán hoặc nhân sự. Tách middleware phân quyền giúp hệ thống dùng lại logic này ở nhiều API và hạn chế việc kiểm tra quyền rải rác trong từng hàm xử lý.

Bốn lớp bảo mật API cần vận hành cùng nhau

Lớp bảo mật	Rủi ro chính được xử lý	Ví dụ áp dụng
Input Validation	Dữ liệu thiếu, sai định dạng hoặc chứa nội dung nguy hiểm	Kiểm tra email, password và làm sạch dữ liệu
Rate Limiting	Brute force và request dồn dập làm quá tải máy chủ	Giới hạn số lần gọi API login theo IP
Authentication	Truy cập trái phép vào dữ liệu riêng tư	Xác minh JSON Web Token trong header
Authorization	Người dùng vượt quyền thực hiện thao tác nhạy cảm	Chỉ admin được phép xóa sản phẩm

Bốn lớp này không hoạt động độc lập. Input Validation ngăn dữ liệu xấu đi vào hệ thống, Rate Limiting giảm áp lực từ request bất thường, Authentication xác minh danh tính và Authorization giới hạn phạm vi hành động của từng vai trò.

Trong dự án có hàng chục hoặc hàng trăm API, thách thức không chỉ là viết middleware. Bạn còn cần tổ chức mã nguồn để dễ mở rộng, theo dõi các lớp bảo mật có hoạt động đúng hay không, phát hiện lỗi nhanh và xử lý khi sự cố xảy ra.

FAQ

Có cần validate ở frontend khi backend đã validate không?

Có. Validate ở frontend giúp người dùng nhận phản hồi nhanh và cải thiện trải nghiệm nhập liệu. Tuy nhiên, validate ở backend vẫn là bắt buộc vì request có thể được gửi trực tiếp đến API mà không đi qua giao diện.

Authentication và Authorization khác nhau thế nào?

Authentication xác minh danh tính, tức kiểm tra người dùng đã đăng nhập hợp lệ hay chưa. Authorization kiểm tra quyền, tức người dùng đó có được phép thực hiện hành động cụ thể hay không.

Vì sao không nên lưu mật khẩu trong JSON Web Token?

Token chỉ nên chứa thông tin cần thiết như ID và quyền người dùng. Mật khẩu và các dữ liệu nhạy cảm không nên được đưa vào token để tránh tạo thêm rủi ro bảo mật.

Nếu website hoặc phần mềm của bạn cần thiết kế backend có kiểm soát dữ liệu, phân quyền và luồng API ổn định, dịch vụ thiết kế website và SEO của MintStack có thể là một điểm khởi đầu phù hợp.