Rate Limiting là gì? Kiểm soát Request Abuse

Rate limiting là cơ chế giới hạn số lượng request mà một client, user, API key hoặc một nhóm định danh được phép gửi trong một khoảng thời gian. Mục tiêu không phải là “chặn càng nhiều càng tốt”, mà là giữ tài nguyên cho traffic hợp lệ, giảm request abuse và ngăn một luồng tự động chiếm quá nhiều năng lực xử lý của website.

Rate limiting thường được đặt ở CDN/WAF, API gateway, reverse proxy hoặc ngay trong ứng dụng. Vị trí triển khai quyết định bạn nhìn thấy tín hiệu gì và có thể giới hạn theo khóa nào. Ở edge, hệ thống có lợi thế chặn request trước khi tới origin; trong application, bạn có thể hiểu rõ user, tenant và thao tác nghiệp vụ hơn.

Rate limiting hoạt động như thế nào?

Một rule rate limiting thường có bốn thành phần: scope để xác định request nào áp dụng; key để nhóm request theo IP, user, API key hoặc thuộc tính khác; window/threshold để xác định tốc độ cho phép; và action như log, throttle, challenge hoặc block.

Ví dụ, thay vì đặt một ngưỡng chung cho toàn website, bạn có thể giới hạn riêng cho /login, /search, /api/ hoặc form gửi dữ liệu. Đây là cách phù hợp hơn vì chi phí xử lý và hành vi hợp lệ của từng endpoint khác nhau.

Fixed window, sliding window và token bucket

Các nền tảng có thể dùng thuật toán khác nhau. Fixed window đếm request trong từng khung thời gian cố định và dễ triển khai nhưng có thể tạo burst ở ranh giới hai cửa sổ. Sliding window theo dõi phân bố request mượt hơn. Token bucket cho phép một lượng burst ngắn trong khi vẫn kiểm soát tốc độ dài hạn. Không có thuật toán nào mặc định “tốt nhất”; lựa chọn phụ thuộc traffic pattern và khả năng của nền tảng.

Rate limiting giúp kiểm soát những loại request abuse nào?

Brute force và credential stuffing: nhiều lần thử đăng nhập hoặc xác thực liên tiếp.
Spam form: bot gửi contact form, comment, đăng ký tài khoản hoặc yêu cầu OTP với tốc độ bất thường.
API abuse: client gọi endpoint quá nhanh, batch quá lớn hoặc lặp lại thao tác đắt tài nguyên.
Scraping: crawler thu thập dữ liệu với tốc độ vượt mức sử dụng thông thường.
Layer 7 flood: request HTTP có vẻ hợp lệ nhưng được gửi với số lượng hoặc tần suất đủ lớn để tạo áp lực lên backend.

Rate limiting không thay thế WAF hay DDoS protection. WAF tập trung vào logic lọc request theo rule và dấu hiệu tấn công; DDoS mitigation xử lý bài toán lớn hơn về khả năng hấp thụ lưu lượng; còn rate limiting đặc biệt hữu ích khi request trông hợp lệ nhưng tần suất hoặc chi phí xử lý của chúng trở nên bất thường. Xem thêm kiến trúc giảm thiểu DDoS bằng CDN, WAF, Rate Limit và Origin Protection. Hai failure mode thực tế đáng đối chiếu là Bot Traffic được kiểm soát bằng Rate Limiting và HTTP Flood làm quá tải WordPress/PHP-FPM.

Đừng chỉ giới hạn theo IP

IP là key phổ biến vì dễ có ở lớp edge, nhưng nó không phải định danh hoàn hảo. Nhiều user hợp lệ có thể dùng chung IP qua NAT, mạng doanh nghiệp, carrier-grade NAT hoặc VPN. Ngược lại, attacker có thể phân tán request qua nhiều IP.

Nếu nền tảng cho phép, hãy cân nhắc key phù hợp với ngữ cảnh: user ID sau đăng nhập, API key, session, tenant, token, device signal hoặc tổ hợp nhiều thuộc tính. Với endpoint chưa xác thực, IP vẫn hữu ích nhưng nên kết hợp các tín hiệu khác thay vì coi IP là danh tính tuyệt đối.

Cách chọn threshold an toàn

Không nên sao chép một con số cố định từ tài liệu khác rồi áp dụng cho mọi website. Threshold cần dựa trên baseline thực tế: request rate bình thường, peak hợp lệ, số người dùng chia sẻ cùng một nguồn mạng, độ đắt của endpoint và mức chịu tải của origin.

Thu thập log theo endpoint và định danh trong một khoảng đủ đại diện.
Tách traffic người dùng, automation hợp lệ và traffic đáng ngờ.
Xác định percentile hoặc dải peak hợp lệ thay vì chỉ nhìn trung bình.
Đặt ngưỡng thử nghiệm cao hơn peak hợp lệ một khoảng an toàn.
Chạy ở chế độ log/count nếu nền tảng hỗ trợ.
Quan sát false positive trước khi chuyển sang challenge, throttle hoặc block.

Cùng một con số như “100 request/phút” có thể được đếm và enforce khác nhau giữa các nền tảng. Security Lab Cloudflare vs AWS WAF Rate Limiting phân tích cụ thể counting key, aggregation, time window và enforcement để tránh copy threshold mà không hiểu semantics.

Với luồng đăng nhập WordPress, có thể tham khảo quy trình riêng trong bài bảo vệ wp-login.php bằng WAF và Rate Limiting.

Rate limiting ở CDN/WAF hay origin?

Triển khai ở edge có lợi thế giảm request đi vào hạ tầng gốc. Điều này đặc biệt quan trọng khi mục tiêu là bảo vệ CPU, worker, database hoặc upstream service. Tuy nhiên, edge có thể thiếu ngữ cảnh nghiệp vụ mà application nắm được.

Mô hình tốt thường là nhiều lớp: edge rule để chặn burst rõ ràng; API gateway để quản lý quota theo client hoặc key; application để bảo vệ thao tác nhạy cảm theo user, tenant hoặc trạng thái giao dịch.

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

Đối với API, HTTP 429 Too Many Requests là response thường dùng khi client vượt giới hạn. Tùy kiến trúc, server có thể kèm thông tin retry phù hợp. Với browser traffic, một số WAF/CDN hỗ trợ managed challenge hoặc hành động giảm tốc thay vì block cứng ngay lập tức.

Không nên dùng một response chung cho mọi tình huống. Một crawler hợp lệ vượt nhẹ ngưỡng có thể được throttle; một nguồn đang credential stuffing có thể cần challenge hoặc block; một API client trả phí có thể cần quota riêng theo contract.

Những lỗi cấu hình rate limiting thường gặp

Ngưỡng quá thấp: chặn user thật trong giờ cao điểm.
Ngưỡng quá cao: rule tồn tại nhưng không giảm tải đáng kể.
Chỉ dùng IP: gây false positive cho NAT/VPN và dễ bị phân tán qua botnet/proxy.
Áp dụng cùng một rule cho mọi path: bỏ qua khác biệt về chi phí xử lý.
Không test critical flow: login, checkout, upload, webhook hoặc API integration có thể bị gián đoạn.
Không quan sát origin: edge tưởng đã ổn nhưng backend vẫn quá tải do endpoint đắt tài nguyên.

Checklist triển khai rate limiting

Inventory các endpoint và critical flow.
Xác định endpoint dễ bị brute force, spam, scraping hoặc resource abuse.
Chọn key phù hợp với từng endpoint.
Lấy baseline từ log và analytics.
Tạo rule ở chế độ quan sát trước khi enforce nếu có thể.
Kiểm tra false positive với user, mobile network, NAT, VPN và integration hợp lệ.
Theo dõi 429/challenge/block rate, latency, error rate và tải origin.
Chuẩn bị rollback hoặc tăng threshold nhanh khi có tác động ngoài ý muốn.

Rate limiting không phải là một con số cố định

Giá trị của rate limiting nằm ở việc ràng buộc mức tiêu thụ tài nguyên theo ngữ cảnh, không phải ở một “magic number”. OWASP API Security Top 10 coi việc thiếu giới hạn phù hợp cho tần suất hoặc mức tiêu thụ tài nguyên là một rủi ro phổ biến đối với API. Vì vậy, rule tốt cần phản ánh chi phí thật của endpoint và hành vi hợp lệ của client.

Nếu website đang gặp HTTP flood hoặc traffic tăng bất thường, hãy kết hợp rate limiting với cache, WAF, DDoS mitigation và kiểm soát origin. Bài Layer 7 DDoS và cách nhận biết HTTP Flood giúp phân biệt request abuse với traffic spike thông thường.

Kết luận

Rate limiting là một control quan trọng để bảo vệ website và API khỏi request abuse, nhưng cần được tune theo endpoint, định danh và baseline thực tế. Hãy bắt đầu bằng quan sát, chọn key đúng, bảo vệ critical flow trước, triển khai từng bước và luôn theo dõi false positive sau khi enforce.

Nguồn tham khảo: OWASP API Security Top 10 – API4:2023 Unrestricted Resource Consumption; Cloudflare documentation về rate limiting, WAF và bot protection.