APIs are designed for automated scheduling and thus vulnerable to network attacks caused by automated scheduling.
Attackers attempt to use replays to automatically send volumes of business traffic with different authentication credentials, resulting in data leakage.
By using automated tools to launch Layer-7 DDoS attacks, attackers initiate continuous requests and occupy the bandwidth of the server and upstream and downstream computing and storage resources, resulting in business instability.
Fuzz testing tools can be also used to conduct targeted attacks and bypass security measures.
In addition, attackers can write automated programming tools to perform resource exhaustion attacks.
Given these threats, APIs can be protected by the following modules.
API capacity protection
API security protection
API asset management
API lifecycle management
This article describes how to implement API capacity protection. Note that during the development lifecycle, the API system stability can be protected and boosted by using caching, downgrading, and rate limiting measures.
Cache
Degrade
Rate limits
Increase system access speed and system processing capacity.
When the service or the core process is affected, temporarily block the API access, and unblock after the peak time or the problem is solved.
The system is protected by limiting the rate of concurrent access requests or the rate of requests within a time window. Once the rate limit is reached, services can be denied, queued or waited, and downgraded.
Although these effective protection measures can be implemented in the process of development, operation and deployment, they are too cost-consuming and throughout the lifecycle of API security, it is necessary to provide API capacity protection for all API assets.
Therefore, adjustments need to be made for each API, leading to exponentially increased workload. You can quickly protect the capacity of business APIs with the following methods.
Note
API analytics is currently in beta and only supports 3 domain names. Submit a ticket if you need to use it.
How to protect the capacity of APIs?
When protecting API capacity, in addition to the measures described above, you can also use the API capacoty module in WAF. This article explains the following 9 methods for target APIs.
Protection Method
Description
API content caching
Cache static API resources.
API access downgrade
Block API exceptional traffic to protect business system stability.
API rate limiting
Limit the overall access request rate of the API.
API scheduling rate limiting
Limit the access speed of the client scheduling API.
Protection for API sensitive calls
Protect sensitive APIs from scheduling abuse and ensure no data breach.
Protection for API resources
Protect API resources from being overused.
Protection for key APIs
Perform 2FA/MFA authentication when key APIs are scheduled.
API signature verification
Verify that the client is a real client for access.
API exception scheduling protection
Protect the API from being accessed by abnormal resources.
API Content Caching
Public APIs are frequently called to return content using a lot of resources. If the content will not be continuously updated for a period of time, the content can be cached to reduce computing and bandwidth resources of the API server.
Here you can use the Web tamper protection module in Basic Security to quickly cache the API content.
1. On the page displayed, click Add rule, and the rule adding window will pop up.
2. In the pop-up window, configure relevant fields and click OK.
Field description:
Rule name: The rule name can be up to 50 characters. You can search for rules by name in attack logs.
Page path: Path of the page to be protected from tampering. You need to enter a specific URL rather than a path.
Note
The specified page is limited to static resources such as .html, .shtml, .txt, .js, .css, .jpg, and .png.
After the rule is added, when a user accesses this page for the first time, WAF will cache the page, and subsequent access requests will be directed to the WAF-cached page.
3. After the tamper protection rule is added, it will be enabled by default.
API Rate Limiting
API rate limiting involves two parts:
Limiting API speed
If API speed limits are imposed on the server, some clients may be unable to access business. When APIs are attacked by a large amount of traffic and the API speed is limited on the backend, most of the access traffic will be considered exceptional and blocked. So it is recommended to limit the client calls.
Limiting API calls
The API calls allowed for each client can be restricted through CC protection and bot management.
CC protection settings
With CC protection, you can set the overall access frequency of each client. Once the client exceeds the expected limit, it will be handled as configured.
2. In the Add rule window displayed, configure the parameters and click OK.
Bot management settings
Go to Bot management > Bot protection, configure the average session speed to control the continuous access speed of each client.
1. In the Scene management module, view the target scene by clicking View configuration.
2. Click Add rule, configure parameters, and click OK.
Session settings
With the dramatically growing number of IPv4 IPs in the current network, many IP operators have started using a NAT IP, which allows multiple business clients to use one public IP. If rate limits are only enforced on business IPs that share one NAT IP, IP rate limiting can be easily triggered with false positives. However, restricting the number of requests made will be much less effective if the rate limits are set too high.
Therefore, you can configure session settings, which can automatically distinguish different clients under the same IP and impose business rate limits for a single client.
Session settings
1. Log in to the WAF console and select Basic Security on the left sidebar.
2. On the basic security page, select the target domain name in the top-left corner and click CC protection.
3. In the Session settings module, click Set.
4. Configure parameters and click OK.
Parameter description:
Session position: Select HEADER, COOKIE, GET, or POST, where GET and POST are HTTP request parameters rather than HTTP headers.
Match mode: Except HEADER (only supports position match), all support matching by string pattern or position.
Session ID: The identifier of the session. It can be up to 32 characters.
Start position: Specify the start of the string or the position. It is an integer between 1 and 2048 and only up to 128 characters can be extracted.
End position: Specify the end of the string or the position. It is an integer between 1 and 2048 and only up to 128 characters can be extracted.
2. On the session management page, click Add a configuration, configure parameters and click OK.
Note
A token ID should be a continuous tracking ID, such as the value of set-cookies after login.
Parameter description:
Token location: Select HEADER, COOKIE, GET, or POST, where GET and POST are HTTP request parameters rather than HTTP headers.
Token ID: The identifier of the Token.
Limiting API calls
Each sensitive API should have a limit on the number of calls. For example, if the SMS API service is not rate-limited, the APIs could suffer abusive consumption and incur excessive charges. If these sensitive APIs are verified by 2FA/MFA or other authentication techniques before being called, abnormal API scheduling can be effectively reduced.
You can limit API calls in Bot management > Bot protection.
Performing authentication before sensitive API calls
Limiting the total API calls per client can make within a session
How to authenticate the client access to APIs?
There are many ways to verify the client's signature, including but not limited to:
Mutual TLS authentication.
Client signature verification.
Client challenge authentication.
Authentication can be enhanced by applying mTLS and client signature challenges, etc.
Meanwhile, browser bot defence can be enabled in WAF to authenticate API data on the client side. For more details, see Client Risk Identification.
Yes
No
Was this page helpful?