Bảo vệ API & Endpoint bằng Rate Limiting

Rate limiting cho API không chỉ là đặt một ngưỡng request chung. Với endpoint nhạy cảm như đăng nhập, gửi OTP, quên mật khẩu, tạo tài khoản, tìm kiếm, upload, checkout hoặc các thao tác làm thay đổi dữ liệu, mỗi request có chi phí và rủi ro khác nhau. Vì vậy, cách bảo vệ hiệu quả là thiết kế giới hạn theo endpoint, định danh client và mức tiêu thụ tài nguyên thực tế.

OWASP API Security Top 10 2023 xếp Unrestricted Resource Consumption vào nhóm rủi ro quan trọng: API có thể bị lạm dụng khi thiếu giới hạn phù hợp cho tần suất gọi, kích thước payload, số phần tử xử lý, batch operation hoặc chi phí từ dịch vụ bên thứ ba.

Endpoint nào cần ưu tiên rate limiting?

Không phải endpoint nào cũng cần cùng một policy. Hãy ưu tiên những nơi có một trong các đặc điểm sau:

Authentication: login, refresh token, password reset, OTP verification.
Account lifecycle: signup, invite, email verification, thay đổi thông tin nhạy cảm.
Expensive read: search, report, export, filter phức tạp, truy vấn dữ liệu lớn.
Write operation: tạo order, comment, booking, ticket, upload hoặc mutation.
Third-party cost: endpoint kích hoạt SMS, email, payment, AI API hoặc dịch vụ tính phí theo request.
High-value business flow: checkout, coupon, inventory hold, gift card, reservation.

Rate limit theo IP là chưa đủ

IP hữu ích cho traffic chưa xác thực nhưng có nhiều giới hạn. Một văn phòng, trường học hoặc mạng di động có thể khiến nhiều user dùng chung một public IP. Ngược lại, automation xấu có thể xoay IP qua proxy, botnet hoặc cloud provider.

Sau khi xác thực, nên cân nhắc key gần với identity thật hơn như user ID, API key, client ID, tenant, session hoặc token. Với hệ thống nhiều tenant, policy theo tenant giúp tránh một khách hàng tiêu thụ quá nhiều tài nguyên của toàn hệ thống.

Thiết kế policy theo từng loại endpoint

Không nên chỉ đếm theo IP. Một policy có thể kết hợp giới hạn theo account identifier và theo IP để giảm brute force phân tán hoặc credential stuffing. Hành động có thể chuyển dần từ log sang challenge, delay hoặc block tùy độ tin cậy của tín hiệu.

OTP và password reset

Đây là nhóm endpoint vừa nhạy cảm vừa có khả năng phát sinh chi phí trực tiếp. Ngoài request rate, cần giới hạn số lần gửi mã, số lần verify sai và tổng số thao tác theo user hoặc destination trong một khoảng thời gian. Điều này giúp giảm spam, SMS pumping và abuse workflow.

Search, report và export

Đây thường là endpoint tốn CPU hoặc database hơn request đọc đơn giản. Rate limiting nên đi cùng giới hạn page size, maximum records, query complexity và timeout. Chỉ giới hạn số request mà bỏ qua kích thước hoặc độ phức tạp có thể vẫn để attacker làm cạn tài nguyên bằng ít request nhưng rất đắt.

Upload và xử lý file

Cần kiểm soát cả tần suất lẫn kích thước file, số file mỗi request và tài nguyên xử lý sau upload. Một request upload lớn có thể tạo thumbnail, scan malware hoặc chạy pipeline khác, vì vậy chi phí không tỷ lệ đơn giản với số request.

Quota và rate limit khác nhau thế nào?

Rate limit thường kiểm soát tốc độ trong cửa sổ ngắn, ví dụ số request trong vài giây hoặc phút. Quota kiểm soát tổng mức sử dụng trong khoảng dài hơn như giờ, ngày hoặc billing cycle. API public hoặc SaaS thường cần cả hai.

Một client có thể không vượt tốc độ tức thời nhưng vẫn tiêu thụ quá nhiều tài nguyên trong ngày. Ngược lại, client còn nhiều quota nhưng tạo burst quá lớn trong vài giây. Hai control giải quyết hai vấn đề khác nhau.

Đừng bỏ qua GraphQL và batching

Với GraphQL hoặc endpoint hỗ trợ batch, một HTTP request có thể chứa nhiều operation. Nếu rate limiter chỉ đếm request ngoài cùng, attacker có thể nhét nhiều thao tác đắt tài nguyên vào một request. Policy cần xem xét operation count, query depth/complexity, batch size hoặc cost model nếu nền tảng hỗ trợ.

Chọn threshold bằng baseline, không bằng cảm tính

Không có một con số universal cho login, OTP hay API. Threshold phải dựa trên traffic hợp lệ và giới hạn tài nguyên thực tế.

Đo request rate theo endpoint và key.
Xác định peak hợp lệ và pattern theo thời gian.
Đo latency, error rate, CPU, database load hoặc third-party cost khi tải tăng.
Đặt policy thử nghiệm ở mức không ảnh hưởng user thật.
Quan sát log/count trước khi enforce nếu có thể.
Tune theo false positive và hành vi abuse quan sát được.

Nếu bạn mới xây nền tảng rate limiting tổng thể, hãy đọc trước bài Rate Limiting là gì và cách kiểm soát request abuse.

Response khi client vượt giới hạn

HTTP 429 Too Many Requests là response phổ biến cho API khi vượt rate limit. Tùy hệ thống, response có thể cung cấp thông tin retry hoặc quota còn lại. Tuy nhiên, không nên tiết lộ quá nhiều chi tiết nếu thông tin đó giúp attacker tối ưu chiến thuật né giới hạn.

Với endpoint đặc biệt nhạy cảm, thay vì block cứng ngay lập tức, bạn có thể dùng delay, challenge, tăng friction hoặc yêu cầu bước xác minh bổ sung. Enforcement nên phù hợp với risk và trải nghiệm người dùng.

Kết hợp rate limiting với các lớp kiểm soát khác

Rate limiting là một lớp, không phải toàn bộ API security. Một kiến trúc phòng thủ tốt có thể kết hợp:

Authentication và authorization đúng thiết kế.
Schema và input validation.
WAF hoặc API gateway để lọc request bất thường.
Bot protection cho automation abuse.
Rate limiting và quota theo endpoint/client.
Timeout, payload limit và pagination limit.
Logging, alerting và cost monitoring.
Origin protection để attacker không bypass lớp edge.

Nếu rate limit đặt ở CDN/WAF nhưng origin vẫn truy cập trực tiếp từ Internet, attacker có thể bỏ qua policy edge. Bài Origin Protection và cách ngăn bypass CDN/WAF giải thích lớp kiểm soát này.

Telemetry cần theo dõi

Request rate theo endpoint, user, key hoặc tenant.
Tỷ lệ 429, challenge và block.
Latency và error rate trước/sau khi enforce.
Top client hoặc key tạo tải cao.
CPU, memory, database connection và queue depth.
Chi phí SMS, email, payment hoặc third-party API.
False positive từ mobile network, partner integration hoặc batch job hợp lệ.

Quy trình triển khai an toàn

Inventory: liệt kê endpoint, owner và critical flow.
Classify: đánh dấu endpoint theo sensitivity và cost.
Baseline: thu thập traffic hợp lệ.
Design: chọn key, window, threshold và action.
Dry-run: log/count nếu nền tảng hỗ trợ.
Pilot: enforce trên một endpoint hoặc nhóm client nhỏ.
Verify: kiểm tra functional flow và telemetry.
Expand: mở rộng policy sau khi false positive được kiểm soát.
Review: điều chỉnh khi traffic hoặc business flow thay đổi.

Những lỗi thường gặp

Áp một threshold cho toàn bộ API.
Chỉ giới hạn theo IP.
Không giới hạn payload, page size hoặc batch size.
Không phân biệt endpoint rẻ và endpoint đắt tài nguyên.
Không có quota cho dịch vụ tính phí.
Không test partner integration hoặc mobile app.
Không có rollback khi policy chặn nhầm.

Kết luận

Bảo vệ API bằng rate limiting hiệu quả nhất khi policy phản ánh đúng identity, endpoint và resource cost. Hãy ưu tiên authentication, OTP, search, upload và các thao tác có tác động tài chính; kết hợp request rate với quota, payload limit và telemetry; sau đó enforce từng bước dựa trên baseline thực tế.

Nguồn tham khảo: OWASP API Security Top 10 2023 – API4 Unrestricted Resource Consumption; tài liệu Cloudflare về API security, rate limiting và bot mitigation.