Recently, people always ask me, high defense CDN in the end can not prevent API attacks? This is a good question, indicating that we are finally starting to care about the real business security - after all, these days, just a crawler or malicious calls can be made to the interface collapse, not to mention those specifically for the API CC attacks and injection penetration.
I directly say the conclusion: yes, but definitely not open a CDN on everything. You have to understand, high-defense CDN is essentially a “traffic cleaning + intelligent scheduling” system, and API protection belongs to a more refined WAF (Web Application Firewall) category. Many vendors publicize “one key protection API”, in fact, behind a bunch of configurations piled up, if you believe the ad words, that is not far from being brushed.
I first spit a little: many people think that if you buy a high-defense CDN, the API is automatically safe. As a result of the attack, found that the interface response is slow as a snail, a check of the logs, all malicious requests bypassing the caching rules, directly to the source station. This is really not CDN can not, but you did not tell the CDN “which is the API” “how to prevent”.
How is an API attack different from a regular web attack?
APIs are often the core of the business, with frequent data interactions, and many are dynamic requests that can't rely on caching to carry the traffic. Attackers like to focus on the API to play, because once the protection is bypassed, you can directly get the data and even lift the right. I have tested, a did not do rate limitation of the login interface, a single IP request hundreds of times a second, the server CPU directly soared full - and this is only a primary attack.
More ruthless is the kind of low-frequency slow attack, simulating normal user behavior, every few seconds to adjust the key API. this request seems harmless, but a day down can consume you hundreds of thousands of database queries, and the traditional WAF is difficult to find. Therefore, API protection must be “refined”, just rely on IP blacklists and basic CC protection is absolutely not enough.
How to do API protection with high defense CDN? The core is just three points: identification, rules, linkage.
First you have to let the CDN know which paths are APIs. e.g. your user login interface is /api/v1/loginThe order inquiry is /graphqlThese have to be explicitly told to the CDN: “These are interfaces, don't treat them as static resources”. The good thing is that the major vendors support path matching, and can even override dynamic routing with regular expressions.
For example, in the CDN5 console, you can configure the API path rules like this:
What this set of rules means is: all API interfaces matched to accept up to 100 requests per minute, with no more than 20 short bursts. After exceeding that it's not a direct IP block, but a CAPTCHA pop-up - after all, it's worse to accidentally hurt a real user than to let a bot off the hook.
But it's not enough to limit the flow, you have to protect against malicious parameters and injection attacks. This is where WAF rules come in. For example, for SQL injection, you can configure custom rules in the console of CDN07:
Be careful, don't just copy my rules here! In the actual environment, you have to adjust according to the business, otherwise you may mistakenly kill the normal request. I have seen an e-commerce project, product search interface with “union” keywords (such as “brand alliance”), the results were directly blocked by the WAF, a big joke.
Comparison of API protection capabilities of different CDN vendors
I've used no less than ten CDNs, and to be honest, the level of each varies. Like CDN5's API protection is more detailed, supports JSON Body-based detection, and can even parse the GraphQL query structure; while CDN07's advantage lies in the global threat intelligence, which can link the attack patterns of other customers and block malicious IPs in advance.
However, there are some small vendors (I won't name them) “API protection” is a gimmick, in essence, or CC protection in another name, even POST Body can not be detected. If you use this kind, it is equivalent to digging a hole for API security.
Recently I also tested 08Host's overseas nodes and found that their protection strategy for APIs is a bit interesting: not only does it support flow limiting and WAF, but it can also dynamically adjust its strategy according to the interface return status code. For example, if an interface suddenly returns a large number of 500 errors, the system will automatically trigger a meltdown to avoid the avalanche effect - this feature is particularly useful for microservice architecture.
Practical configuration: three steps to build API protection system
The first step is definitely combing through the API assets. It's something that sounds basic, but 80% of teams simply don't do it all. You have to list all the interfaces that are open to the public, including paths, methods (GET/POST), parameters and normal traffic baselines. I recommend exporting directly with Swagger or OpenAPI specification, otherwise organizing it manually can be exhausting.
The second step is to set protection strategies for different interfaces. Sensitive interfaces (such as login, payment) to strictly limit the flow and full-parameter detection, public interfaces (such as the list of products) can be relaxed to limit the flow but anti-crawler. As an example:
The third step is log monitoring and iteration.CDN protection logs must be docked SIEM system or self-built monitoring platform, focusing on false kills and bypass events. I have previously relied on the ELK stack to do a real-time Kanban, found that a certain crawler specializes in 4:00 a.m. low-frequency crawl API, and then added the time dimension rules to completely stop.
Don't ever step into these potholes!
Some people like to come up and set the flow limit value extremely low, as a result, the real users popped the CAPTCHA en masse during the event, and the experience collapsed directly. The correct approach is to first put the observation for a period of time, according to the actual distribution of traffic to set the threshold - for example, take the average request volume of 3 times as the trigger line.
In addition, don't forget that CDN is only a layer of protection, and key APIs have to do secondary validation at the business layer. For example, the interface to modify user data, you must verify the identity token and operating privileges. I once penetration test found a loophole: CDN level put the request, but the server did not check whether the user ID belongs to the current session, resulting in overstepping the right to access.
There are also certificate and encryption issues.API must be full-link HTTPS, and have to update the certificate regularly. I've seen too many tragedies where the CDN fails to return to the source because of an expired certificate, and the API is all 503. Now Let's Encrypt can automatically renew, there is really no reason to make this mistake.
To summarize.
A high-defense CDN protects against API attacks, but requires you to proactively configure and continuously optimize. The core idea is: identify API assets → set up refined rules → monitor iterations. When selecting vendors, focus on WAF detection accuracy, flow limiting dimensions and logging capabilities, like CDN5 and CDN07 are in the first tier, and 08Host is suitable for specific scenarios.
Finally said a solid: API security does not have a once-and-for-all program, attack methods are evolving every day. Even on the best CDN, you have to do regular penetration testing and rule audits. Otherwise, when the data leakage and then remediation, it is not a change of configuration can be resolved.
