API đã trở thành xương sống của hầu hết các ứng dụng hiện đại - từ mobile app, web app cho đến hệ thống microservices giao tiếp với nhau. Nhưng càng mở nhiều cổng giao tiếp, bề mặt tấn công (attack surface) càng lớn. Bài viết này tổng hợp những hình thức bảo mật API quan trọng nhất mà bất kỳ ai xây dựng backend cũng nên nắm vững.
1. Rate Limiting
Rate Limiting là kỹ thuật giới hạn số lượng request mà một client (theo IP, API key, hoặc user) có thể gửi đến API trong một khoảng thời gian nhất định.
Tại sao cần thiết:
- Ngăn chặn tấn công brute-force (dò mật khẩu, dò OTP)
- Chống lại DDoS ở tầng ứng dụng
- Bảo vệ tài nguyên server, tránh quá tải khi có traffic bất thường
- Đảm bảo công bằng giữa các client khi dùng chung hạ tầng
Cách triển khai phổ biến:
- Fixed Window: đếm số request trong mỗi khung thời gian cố định (VD: 100 request/phút)
- Sliding Window: chính xác hơn Fixed Window, tránh hiện tượng "burst" ở ranh giới khung thời gian
- Token Bucket: mỗi client có một "giỏ token", mỗi request tiêu tốn 1 token, token được nạp lại theo thời gian
- Leaky Bucket: xử lý request theo tốc độ cố định, request dư sẽ bị xếp hàng hoặc loại bỏ
Ở tầng hạ tầng, có thể dùng Nginx, API Gateway (Kong, AWS API Gateway), hoặc Redis để implement rate limiting hiệu quả mà không ảnh hưởng performance của backend chính.
2. CORS (Cross-Origin Resource Sharing)
CORS là cơ chế bảo mật của trình duyệt, kiểm soát việc một trang web ở domain này có được phép gọi API ở domain khác hay không.
Vấn đề CORS giải quyết: Mặc định, trình duyệt chặn các request cross-origin (khác domain/port/protocol) vì lý do bảo mật (Same-Origin Policy). CORS cho phép server "mở cửa" một cách có kiểm soát cho các domain được tin tưởng.
Một số lưu ý khi cấu hình:
- Tuyệt đối tránh dùng
Access-Control-Allow-Origin: *kết hợp vớiAccess-Control-Allow-Credentials: true- đây là cấu hình nguy hiểm, có thể lộ thông tin nhạy cảm - Chỉ whitelist các domain thực sự cần thiết, tránh cấu hình quá lỏng lẻo
- Cẩn thận với preflight request (
OPTIONS) khi API có custom headers hoặc method đặc biệt (PUT, DELETE...)
CORS chỉ bảo vệ ở tầng trình duyệt - nó không thay thế cho việc xác thực (authentication) hay phân quyền (authorization) ở server.
3. SQL/NoSQL Injection
Injection là một trong những lỗ hổng lâu đời nhưng vẫn thường xuyên xuất hiện trong danh sách OWASP Top 10. Kẻ tấn công chèn mã độc vào input để thao túng câu truy vấn cơ sở dữ liệu.
Ví dụ kinh điển (SQL Injection): Nếu backend nối chuỗi trực tiếp từ input người dùng vào câu SQL mà không xử lý, kẻ tấn công có thể chèn ký tự đặc biệt để thay đổi logic truy vấn, từ đó bypass đăng nhập hoặc trích xuất toàn bộ dữ liệu.
NoSQL Injection cũng nguy hiểm tương tự, đặc biệt với MongoDB khi input được truyền trực tiếp dưới dạng object (JSON) vào query mà không kiểm tra kiểu dữ liệu.
Cách phòng chống:
- Luôn dùng prepared statements / parameterized queries, không bao giờ nối chuỗi SQL thủ công
- Dùng ORM (Object-Relational Mapping) đáng tin cậy như Sequelize, TypeORM, Prisma, Hibernate
- Validate và sanitize dữ liệu đầu vào nghiêm ngặt, đặc biệt kiểm tra kiểu dữ liệu (type checking) với NoSQL
- Áp dụng nguyên tắc least privilege cho tài khoản database (không dùng tài khoản root/admin cho ứng dụng)
4. CSRF (Cross-Site Request Forgery)
CSRF là kiểu tấn công khiến người dùng đã đăng nhập vô tình thực hiện một hành động ngoài ý muốn (đổi mật khẩu, chuyển tiền...) thông qua một trang web độc hại, lợi dụng session/cookie đang tồn tại của họ.
Cơ chế tấn công: Trình duyệt tự động gửi kèm cookie khi request đến domain tương ứng, kể cả khi request đó được khởi tạo từ một trang web khác. Nếu API chỉ dựa vào cookie để xác thực mà không có thêm lớp bảo vệ, kẻ tấn công có thể lợi dụng điều này.
Cách phòng chống:
- Sử dụng CSRF token: một token ngẫu nhiên được sinh ra cho mỗi session/form, server kiểm tra token này ở mỗi request thay đổi trạng thái (POST/PUT/DELETE)
- Thiết lập cookie với thuộc tính
SameSite=StricthoặcSameSite=Lax - Kiểm tra header
OriginhoặcRefererđối với các request quan trọng - Với API thuần túy dùng token-based authentication (JWT trong header, không dùng cookie), rủi ro CSRF giảm đáng kể
5. XSS (Cross-Site Scripting)
XSS xảy ra khi kẻ tấn công chèn được mã JavaScript độc hại vào trang web, mã này sẽ thực thi trong trình duyệt của nạn nhân khác.
Ba loại XSS phổ biến:
- Stored XSS: mã độc được lưu trong database (VD: bình luận, tên hiển thị) và hiển thị cho mọi người xem
- Reflected XSS: mã độc nằm trong URL hoặc request, được phản hồi ngay lập tức trong response
- DOM-based XSS: lỗ hổng nằm ở phía client, khi JavaScript xử lý dữ liệu không an toàn và ghi trực tiếp vào DOM
Cách phòng chống:
- Encode/escape output đúng ngữ cảnh (HTML, JavaScript, URL...) trước khi hiển thị
- Áp dụng Content Security Policy (CSP) để giới hạn nguồn script được phép chạy
- Sanitize input, đặc biệt với các trường cho phép rich text/HTML
- Với API, đảm bảo dữ liệu trả về được xử lý đúng cách ở phía frontend, không tin tưởng mù quáng vào dữ liệu từ API khác
6. Firewall
Firewall (tường lửa) là lớp bảo vệ ở tầng mạng, kiểm soát traffic ra/vào hệ thống dựa trên các quy tắc được định nghĩa trước.
Trong bối cảnh bảo mật API, có một số loại đáng chú ý:
- Network Firewall: lọc traffic dựa trên IP, port, protocol
- WAF (Web Application Firewall): hoạt động ở tầng ứng dụng (Layer 7), có thể phát hiện và chặn các pattern tấn công phổ biến như SQL Injection, XSS ngay tại tầng gateway, trước khi request chạm đến ứng dụng
- Cloud-based WAF: các dịch vụ như Cloudflare, AWS WAF cung cấp khả năng lọc traffic độc hại, chặn bot, và tích hợp sẵn rule chống các lỗ hổng OWASP Top 10
Firewall là lớp phòng thủ bổ sung - nó không thay thế cho việc code an toàn ở tầng ứng dụng, nhưng giúp giảm tải và chặn được nhiều cuộc tấn công tự động trước khi chúng đến gần hệ thống.
7. VPN (Virtual Private Network)
VPN tạo ra một đường truyền được mã hóa giữa hai điểm, thường dùng để bảo vệ dữ liệu truyền tải qua mạng công cộng hoặc để giới hạn quyền truy cập vào các API/tài nguyên nội bộ.
Ứng dụng trong bảo mật API:
- Giới hạn API nội bộ (internal API, admin API) chỉ có thể truy cập qua VPN của công ty, không public ra Internet
- Bảo vệ dữ liệu khi giao tiếp giữa các microservices đặt ở nhiều vùng địa lý khác nhau
- Kết hợp với VPC (Virtual Private Cloud) trên các nền tảng cloud để tạo mạng riêng biệt, cô lập với Internet công cộng
VPN đặc biệt hữu ích cho các API quản trị (admin API) hoặc API xử lý dữ liệu nhạy cảm - thay vì để chúng public và dựa hoàn toàn vào authentication, việc giới hạn truy cập mạng ngay từ đầu giúp giảm đáng kể bề mặt tấn công.
Tổng Kết
Không có một giải pháp bảo mật nào là "viên đạn bạc" - bảo mật API hiệu quả đến từ việc kết hợp nhiều lớp phòng thủ (defense in depth):
| Hình thức | Bảo vệ chống lại |
|---|---|
| Rate Limiting | Brute-force, DDoS tầng ứng dụng |
| CORS | Truy cập trái phép từ domain khác qua trình duyệt |
| Chống Injection | Thao túng truy vấn database |
| CSRF Protection | Giả mạo hành động từ người dùng đã đăng nhập |
| Chống XSS | Chèn mã độc thực thi phía client |
| Firewall/WAF | Lọc traffic độc hại ở tầng mạng/ứng dụng |
| VPN | Cô lập tài nguyên nhạy cảm khỏi Internet công cộng |
Việc xây dựng một hệ thống API an toàn đòi hỏi tư duy bảo mật xuyên suốt từ thiết kế, code, hạ tầng, cho đến quy trình vận hành - chứ không chỉ là thêm một vài dòng cấu hình. Hy vọng bài viết đã giúp bạn có cái nhìn tổng quan để áp dụng vào dự án của mình.
