API Defense with Rate Limiting Using FastAPI and Token Buckets

APIs (Application Programming Interfaces) have become the cornerstone of software development for all types of applications. So, ensuring their security is paramount. APIs are often targets for various cyber attacks, serving as the conduits for data exchange between different systems, for mobile apps to streaming apps. One effective security measure to protect APIs is rate limiting, a technique that controls the number of requests a user can make to an API within a given timeframe.

This article delves into the significance of rate limiting in API security, exploring its necessity, implementation, and the challenges it addresses.

If you like my content, please visit Compliiant.io and share it with your friends and colleagues! Cybersecurity services, like Penetration Testing and Vulnerability Management, for a low monthly subscription. Pause or cancel at any time. See https://compliiant.io/

The Necessity of Rate Limiting in API Security

Understanding the Threat Landscape

APIs are inherently exposed to the internet, making them susceptible to a range of cyber threats, including Distributed Denial of Service (DDoS) attacks, brute force attacks, and data scraping. These attacks can lead to service disruptions, data breaches, and system compromises.

Take, for example, my SaaS app Mitigated.io. I designed the system using a microservices architecture. Mitigated.io did not include an API gateway in the design for MVP, predominately for cost reasons. An API gateway typically sits between the front end and the microservices tier. In addition to the many benefits they provide, such as routing, authentication, and balancing, an API gateway usually has rate-limiting capabilities.

Mitigated.io underwent some mysterious consumption periods initially, prompting me to implement some basic limiting features. I hope this helps get you past the initial hurdle and onto a more feature-rich solution, such as an API Gateway or similar function.

The Role of Rate Limiting

Rate limiting serves as a first line of defense against such threats by:

• Preventing Resource Overload: By limiting the number of requests, rate limiting ensures that system resources aren’t overwhelmed by excessive traffic, guarding against DDoS attacks.
• Mitigating Brute Force Attacks: It makes brute force attempts, where attackers try different combinations to gain unauthorized access, less feasible by limiting the number of tries within a certain period.
• Controlling Data Scraping: Automated scripts that scrape data can be thwarted by limiting the number of requests they can make.

Implementing Rate Limiting

Token Bucket Algorithm

A popular method for implementing rate limiting is the token bucket algorithm. This approach generates tokens at a fixed rate, which are then consumed with each API request. Once the tokens are depleted, further requests are denied until new tokens are generated.

Integration with FastAPI

In Python’s FastAPI framework, rate limiting can be implemented as middleware using the token bucket algorithm. This middleware checks the availability of tokens before processing each API request, ensuring compliance with the rate limit.

Sample Code

Python is not my preferred language and this was my first time with FastAPI so my code might not be as optimized as possible. Thanks for your patience. That said, I have complete faith in FastAPI as it’s very lightweight and fast! See below…

Using the token bucket algorithm, this code implements a rate-limiting mechanism for a FastAPI application. The rate-limiting controls the number of API requests a user can make within a specific time frame.

Limiter.py

Token_bucket.py

Key Components:

1. TokenBucket Class: This class represents the token bucket used in the rate-limiting process. It has a maximum capacity of tokens and refills at a specified rate. The bucket starts full and tokens are consumed with each API request. If the bucket is empty, new requests are denied until it refills.
2. RateLimiterMiddleware Class: This is a middleware integrated into the FastAPI application. It uses the TokenBucket instance to determine whether an incoming API request should be processed or denied based on the availability of tokens.

How It Works:

• The TokenBucket class manages the tokens. It refills the tokens based on the elapsed time and deducts a token for each processed request.
• The RateLimiterMiddleware intercepts each incoming request. It checks the token bucket to see if a token is available. If so, the request is processed; otherwise, a 429 Rate Limit Exceeded error is returned.

How to Use:

1. Setup: Place the TokenBucket class in a file named token_bucket.py and the FastAPI application code, including the RateLimiterMiddleware, in main.py.
2. Configuration: In main.py, the token bucket is initialized with a capacity (number of tokens) and a refill rate (tokens added per second). For example, TokenBucket(capacity=4, refill_rate=2) creates a bucket with 4 tokens that refills 2 tokens per second.
3. Integration: The middleware is added to the FastAPI application using app.add_middleware(RateLimiterMiddleware, bucket=bucket). This integrates the rate-limiting functionality into your API.
4. Running the Application: Run your FastAPI application as usual. The rate limiting will automatically apply to all incoming requests.

This solution is not without caveats or limitations. I recommend offloading this type of process to a hardware system like an API Gateway, for example. That said, here are a few items worth mentioning:

1. Single-Instance Limitation: The code is designed for a single-instance application. In a distributed system or when running multiple instances of the application (e.g., in a load-balanced environment), this implementation won’t synchronize the rate limits across instances. This could lead to inconsistent rate limiting.
2. State Persistence: The token bucket state is stored in memory. If the application restarts, the state is lost. This could be problematic in environments where frequent restarts occur.
3. Scalability Concerns: As your application scales, the in-memory solution might not be sufficient. You might need a more robust solution like a distributed cache (e.g., Redis) to maintain the state of the rate limiter.
4. Real-Time Token Refill: The token refill logic is based on the time of request arrival. This means the tokens are effectively refilled only when a request is made, which may not be optimal for all use cases.
5. Lack of User Differentiation: The current implementation applies the same rate limit to all users. In many scenarios, it’s beneficial to have different rate limits for different types of users (e.g., regular users vs. premium users).
6. Complexity in Rate Limiting Configuration: Determining the optimal values for token capacity and refill rate can be challenging. These values greatly depend on the specific use case and traffic patterns of your API.
7. Error Handling and Feedback: The middleware simply returns a 429 Rate Limit Exceeded error without much contextual information. In a user-facing application, you might want to provide more detailed feedback or instructions on how to proceed when the rate limit is hit.
8. Bypassing Mechanisms: Sophisticated users or attackers might find ways to bypass the rate limit, for example, by changing IP addresses or using other evasive techniques.
9. Impact on User Experience: If not calibrated properly, rate limiting can negatively impact the user experience, especially if legitimate requests are being throttled.
10. No Prioritization of Traffic: The current setup does not prioritize certain types of requests over others. In some applications, you might want to implement prioritized queuing where critical API requests are given precedence.

Challenges and Considerations

Scalability

While rate limiting is effective, it poses challenges in a distributed environment. Maintaining a consistent rate limit across multiple instances requires a centralized rate-limiting service or shared data stores like Redis.

Configuration

Determining the optimal rate limit requires a balance. Too strict a limit might hinder legitimate usage, while too lenient a limit might not effectively mitigate threats.

API Diversity

Different APIs may have varying rate limiting needs based on their usage patterns and sensitivity. It’s crucial to tailor rate limits accordingly.

User Experience

Rate limiting, if not implemented thoughtfully, can negatively impact user experience. Providing meaningful error messages and implementing dynamic rate limits based on user behavior can alleviate this issue.

Rate limiting is an essential component of API security, and I hope this helps you and your team in some way.

If you like my content, please visit Compliiant.io and share it with your friends and colleagues! Cybersecurity services for a low monthly subscription. Pause or cancel at any time. See https://compliiant.io/