Closed Guard: Locking Down APIs Against AI-Powered Attacks

One of the most important defensive concepts in Brazilian jiu-jitsu (BJJ) is the guard. When you’re on your back, the guard position lets you use your legs and hips to control the attacker, limit their movement, and prevent them from advancing to a dominant position.

A closed guard, where your legs are locked tightly around your opponent, is especially effective. It shuts down their ability to move freely or launch many attacks, forcing any attacker into a narrow set of options. 

The alternative leaves you reacting to a wave of individual attacks, blocking grips, defending chokes, fighting off every submission attempt. This is a losing battle, because the opponent will just keep varying attacks until one inevitably gets through.

Bypassing some of the leading security products

In issue 277 of APISecurity.io, we highlighted a recent report by Ethiack demonstrating how to bypass signature-based and machine-learning based application security products. 

A cross-site scripting (XSS) vulnerability was discovered in an application, and the goal was to test which security products, if any, could protect the application from being exploited.

Researchers tested web application firewalls (WAFs) and AI-driven behavioral analytics products from Akamai, AWS, Azure, Cloudflare, F5, FortiWeb, Google Cloud, NGINX, and Open-AppSec.

 

 

They discovered that by varying the attack payload, they achieved a 100% bypass rate across every security product tested. 

So why was the security of WAFs and machine-learning tools so ineffective in this case?

It isn’t even a fair fight

An XSS vulnerability in your application is like fighting with a weak shoulder. That’s the vulnerability your attacker wants to exploit. That’s the one that’s really going to hurt.

You need to protect your shoulder. But if you’re in reactive mode, you’re not focused on constraining the attacker, and so they can try any attack against you. Every strike, grip, or choke now has to be countered one by one. Inevitably of course, one breaks through. 

That’s the limitation with these security products. They are reactive rather than proactive.

Take WAFs for example. They come pre-loaded with known attack patterns. If an incoming payload matches that pattern exactly, it gets blocked. But tweak the payload even slightly, and the WAF doesn’t recognize it and the attack sails through. Of course today using AI and automation, attackers can hammer your systems relentlessly until they find a WAF’s blind spots.

Machine learning tools try to improve on WAF limitations by learning new patterns over time. But that learning curve is slow. And when you’re on your back (or in production) taking hits, you don’t have time to learn. An AI-powered attacker only needs to land one shot. The machine-learning tool has to learn, adapt, and block every single one, perfectly. 

“we generated enough traffic so that the alert based payload started being blocked”

In the referenced report, the researchers noted that once the machine-learning tool finally learned to block one attack pattern, the attacker’s AI simply changed the pattern and found another way through, in seconds. 

AI vs. AI isn’t a fair fight. And the results prove it.

Adopt a Closed Guard Approach

The weakness of WAFs and machine learning tools is that they chase attack patterns and anomalies with slow behavioral analytics. A more effective approach is to stop chasing and start enforcing. 

By locking payloads down to the exact formats, ranges, and structures your services require, you dictate the input that is allowed. This narrows what the attacker can do, like a closed guard in BJJ shuts down an opponent’s ability to move freely, forcing them into a narrow set of options.

So how do you achieve this in API security? By using your API documentation.

Take the HTTP parameter pollution attacks used in this case to bypass WAFs:

• q=1‘+1;let+asd=window&q=def=’al’+’ert’+;asd[def](1&q=2);’
• q=1’%0aasd=window&q=def=”al”+”ert”&q=asd[def](1)+’

With a formal definition in your API docs, you can declare q as a string type rather than an array, ensuring it should only occur once:

/search-account:
   get:
     summary: API endpoint returning account information
     parameters:
       - name: q
         in: query
         schema:
           type: string

Enforcing this documented rule at runtime automatically removes HTTP parameter pollution as an option for hackers, since duplicates are simply invalid, and so blocked.

The same applies to the attacks that fooled machine-learning tools:

• q=‘;alert(1),’
• q=test\\’;alert(1);//

By tightening the payload definition further, you restrict what’s a valid input. For example, say the query parameter is used to search for accounts::

/search-account:
   get:
     summary: API endpoint returning account information
     parameters:
       - name: q
         in: query
         schema:
           type: string
           pattern: ^[0-9]{12}$
         description: a unique 12-digit account identifier

Now q must be a 12-digit account ID. Anything else is invalid. The attacker is left with nothing but digits to work with, leaving no space for payload tricks.

That’s the essence of a closed guard approach: stop reacting to endless attacks, and lock down inputs so attackers have no room to move. 

Extend Your API Security Options with 42Crunch

For over 6 years, 42Crunch has pioneered a closed guard approach to API security. This method of locking down inputs to only the formats, ranges, and structures your APIs require is essential to protecting against today’s AI-powered attacks and avoiding costly breaches.

42Crunch delivers a complete API security platform that helps teams:

• Test and validate API definitions for conformance, security, and governance.
• Harden APIs by design with precise, enforceable contracts that define exactly what API payloads are allowed.
• Automate security checks in developer IDEs and CI/CD pipelines to catch vulnerabilities before they reach production.
• Enforce protections at runtime with a containerized API firewall that blocks malicious traffic based on your API’s documented contract.

With 42Crunch, you move beyond reactive defenses and gain a proactive, enforceable security posture that dramatically reduces the attack surface and leaves attackers with no room to manoeuvre.

If you’re ready to explore how 42Crunch can help protect your APIs, contact us today to learn more.

^{Featured image courtesy of @crotalus Unsplash}