Rate Limit Control List (RLCL): targeted, flexible rate limiting

Apinizer's RLCL takes inspiration from Access Control Lists and brings list-based, regex-supported rate limiting — so you can set different limits per user, IP, or partner.

Jul 15, 2024 · 5 min read · Apinizer Team, Platform · Security

Tags: #api-security · #rate-limiting · #access-control · #api-management · #ddos-prevention

Defining targeted and flexible rate limit rules in Apinizer: the RLCL concept and its usage.

Why do we need this?

APIs are everywhere in the digital world. Applications talk to each other, systems share data, devices are constantly connecting. This level of open, intense communication inevitably brings certain security risks. Abuse, attacks, service outages — so it's no longer enough to ask only "who can access?" We also need to ask "who can access how much?"

In the dynamic world of API development and management, controlling the flow of incoming requests is essential to maintain system stability, ensure fair usage, and prevent abuse.

That's exactly where Apinizer comes in.

Our inspiration: Access Control Lists (ACL)

The Access Control List concept, used in security for many years, determines who can access certain resources. It is list-based, target-oriented, and contains clear rules. We thought: "why not use this logic for rate limiting?"

And Rate Limit Control List (RLCL) was born.

ACL vs RLCL: a powerful dual solution

Apinizer offers both ACL and RLCL for security and traffic management. The two complement each other to fully protect your APIs. First define who can access with ACL, then define the limits of that access with RLCL.

So what exactly is RLCL?

As the name suggests: a system that lets you define rate limit rules in a list-based, targeted way. You no longer have to apply a single limit to every IP, every API key, every user. You can define custom limits such as:

5 requests per second for IP 192.168.1.25
500 requests per minute for API keys starting with client-abc-*
10,000 requests per day for specific user IDs

You can also use regex-supported or conditional definitions (e.g. different limits during business hours vs. outside). The era of "one rule for everyone" is over.

How RLCL works in Apinizer

It's not complicated; the steps are clear:

A request arrives.
Identity information is extracted from the request (IP, header, user ID, etc.).
The system checks whether this information is defined in the RLCL (does it match the list or regex?).
If it matches, the rate limit rule defined specifically for it is applied.
If it doesn't match, either the general limit applies or no limit is applied (depending on policy).
If the limit is exceeded, the request is rejected (usually with a 429 Too Many Requests error).
Optionally, rate limit status can be added to response headers (X-RateLimit-*).

RLCL flexibility

Time window options

RLCL supports both Fixed Window and Sliding Window approaches:

Fixed Window. Counters are reset at fixed time intervals (e.g. every hour).
Sliding Window. For any moment, requests in the last X minutes / hours / days are evaluated.

This lets you offer solutions suited to different business scenarios.

Dynamic identity definition

RLCL offers highly flexible options for determining request identity:

IP address
API key
User ID
Request headers
Cookie values
URL parameters
Request body fields

You can even use combinations. For example: "requests with a certain user ID coming from a certain IP block."

Regex support

RLCL lets you build very powerful matching rules using regular expressions. For example:

All IPs starting with ^192\.168\.
All API keys in the format api-key-[0-9]+
Email addresses with a certain domain extension

This reduces management overhead by defining patterns instead of individual values.

Simple, clear settings

We keep our usual ease-of-use principle and offer simple, clear interfaces. The hard part is handled in the background. Without worrying about complex rate limiting algorithms, you can meet all your needs with these settings:

Name and description — for easier management
Execution order — should it run before or after other policies?
Time window type — fixed or sliding?
Allowed request count — how many requests can pass?
Time interval — seconds, minutes, hours, days, or months
Identity variable — IP, API key, or user ID?
Target identities — list or regex
Response headers — show rate limit statistics?

Why RLCL? What's the difference?

Granular control. Clear answers to who can access how much.
Targeted limiting. A single bad actor cannot lock down your entire API.
Flexibility. Partner, customer, service — whoever it is, you can define different SLAs.
Transparency. You can include remaining limit information in responses.
Manageability. Definitions are simple and readable.
Performance. Runs fast with cache support; doesn't slow down your system.

Real-world examples

Free vs premium users. In a freemium service you can apply "100 requests per day" for free users and "50 requests per second" for premium users. Your API stays accessible and fair.
Geography-based protection. You can apply different limits to requests from certain countries or IP blocks. Useful for suspicious traffic sources.
DDoS prevention. Quickly detect IPs sending sudden high traffic and apply special restrictions. Isolate the problem without affecting your other users.
Partner management. Define specific API usage limits for each business partner. Some can make 1,000 requests per minute while others make 10 per hour.

Closing words

We wanted to bring a fresh approach to API security and management. We turned rate limits from just a number into a targeted, flexible, and powerful control tool. Because in the modern API world, "the same rules for everyone" is no longer enough.

Apinizer's RLCL stands out with its adaptable structure for different needs, easy configuration, and strong performance.

With Apinizer, you decide who accesses how much.

All posts · Book a Demo · Read the docs