api_security/rate_limiting

14 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Implement per-tenant rate limiting with tier-based quotas

Define TenantTier enum (FREE, STARTER, BUSINESS, ENTERPRISE) with associated RateLimitConfig containing requests_per_minute, requests_per_day, and burst_size. Implement TenantRateLimiter that checks and enforces both minute-level and daily limits using Redis counters with keys rl:{tenant_id}:min:{minute_epoch} and rl:{tenant_id}:day:{day_epoch}.

Return 429 with Retry-After header when rate limit exceeded

When rate limit is exceeded, return HTTP 429 with JSON body containing error and details. Include Retry-After header with seconds until next available window. Include X-RateLimit-Limit and X-RateLimit-Remaining headers in response.

Tenant tier rate limit configuration values

Use these tier-based limits: FREE tier = 60 requests/minute, 1000 requests/day, 10 burst; STARTER = 300/min, 10000/day, 50 burst; BUSINESS = 1000/min, 100000/day, 100 burst; ENTERPRISE = 5000/min, 1000000/day, 500 burst.

Implement RateLimitMiddleware to enforce tenant limits on all requests

Create RateLimitMiddleware that extracts current tenant context, retrieves tenant tier from database, calls rate_limiter.check_rate_limit(), and returns 429 response if limit exceeded. Add X-RateLimit-Remaining headers to successful responses.

API key requirement and rate limiting

Require API keys for every request to the protected endpoint. Return `429 Too Many Requests` HTTP response code if requests are coming in too quickly. Revoke the API key if the client violates the usage agreement. Do not rely exclusively on API keys to protect sensitive, critical or high-value resources.

SOAP message size limits

SOAP message size should be limited to an appropriate size limit. Larger size limits (or no limit at all) increases the chances of a successful DoS attack.

gRPC message size limits in Go

Set maximum message size limits on the server to prevent resource exhaustion and denial-of-service. Create server with: grpc.NewServer(grpc.MaxRecvMsgSize(4*1024*1024), grpc.MaxSendMsgSize(4*1024*1024)) to limit both receive and send messages to 4MB.

gRPC streaming resource protection

Limit streaming sessions and message counts to prevent resource exhaustion. Monitor and enforce maximum messages per stream and maximum session duration.

gRPC rate limiting implementation in Go

Implement rate limiting with golang.org/x/time/rate.Limiter. Create a RateLimiterStore with map[string]*rateLimiterEntry tracking client IPs to rate limiters and last seen times. In interceptor, extract client IP with getClientIP(ctx), retrieve or create limiter entry with rate.NewLimiter(rate.Limit(10), 20) for 10 req/sec with burst of 20. Check entry.limiter.Allow() and return status.Errorf(codes.ResourceExhausted, "rate limit exceeded") if false. Periodically clean up old limiters (older than 1 hour).

gRPC production rate limiting

For production environments, use external rate limiting solutions like Redis or dedicated services instead of in-memory implementations.

gRPC server-side timeout configuration in Go

Implement defensive timeouts to prevent resource exhaustion from long-running requests. Check if client set a deadline with ctx.Deadline(); if deadline exists and time remaining is less than desired timeout (e.g., 5 seconds), use existing deadline. Otherwise, create new timeout context with context.WithTimeout(ctx, 5*time.Second) and defer cancel().

gRPC timeout configuration

Configure both client-side and server-side timeouts appropriately for your use case to prevent resource exhaustion from long-running requests.

Rate limiting controls for DoS defense

Rate limiting controls include: (1) Define a minimum ingress data rate limit and drop connections below that rate (protect against slow HTTP attacks; inspect logs to avoid impacting legitimate clients). (2) Define an absolute connection timeout. (3) Define a maximum ingress data rate limit and drop connections above that rate. (4) Define a total bandwidth size limit to prevent bandwidth exhaustion. (5) Define a load limit specifying the maximum number of users allowed to access a resource at any given time.

Rate limiting implementation scope

Rate limiting can be implemented at infrastructure level or application level, and can be based on offending IPs, IP block lists, geolocation, or other criteria.

Give your agent this brain