Infinite payloads? The future of API Testing with dynamic fuzzing

What if we told you that our newly released API Scanner has 922 quintillion payloads for a single type of vulnerability test? A quintillion is a billion billion – an immense number that highlights the limitations of traditional API security testing. Old methods like relying on signatures, vulnerability-specific payloads, or a fixed set of fuzzing inputs just aren’t enough anymore, especially when dealing with custom-built software and unique API endpoints.

A fixed set of payloads can’t find new and unknown vulnerabilities. The future (now present) of API security testing requires a new approach that can generate a nearly infinite set of payloads to keep pace with new and evolving threats, such as Prompt Injection. 

In security testing, a payload is a specific string of text or data designed to interact with an application in an unintended way. For instance, a payload for an SQL Injection attack might be ‘ OR 1=1–, while a Cross-Site Scripting (XSS) payload could be <script>alert(‘XSS’)</script>. A payload for a Prompt Injection vulnerability could look like this:

Traditional API security scanners use static word lists, which are files containing a finite number of known payloads. Traditional scanners limit the volume of payloads they test for. If they were to attempt to test a massive array of payloads, it would be slow and costly for the vendor to execute. This brute-force approach is fundamentally limited because it can only find what it knows to look for.

A more advanced approach to API fuzzing (a security testing technique that involves feeding malformed or unexpected data into an application to see how it responds) relies on a basically “infinite” body of payloads. Instead of relying on a finite list, the security tool can generate a virtually limitless number of unique payloads on the fly. But with a list this large, how does a tester or a security scanner manage what to test? The answer lies in the seed number.

What is the “seed number” concept?

Much like a seed in the game Minecraft generates a unique and expansive world, a seed number for API fuzzing deterministically generates a specific subset of payloads from an “infinite” list. This ensures that the same seed will always produce the same payloads, which allows for reproducible and manageable scans without the need to store a massive word list. The new API scanner can generate a nearly infinite set of payloads, with over 922 quintillion for prompt injection alone, which allows it to try new things with every scan while still running all the standard tests.

How can machine learning make scanning smarter?

The true power of the seed number approach is leveraged when combined with machine learning principles. The system can learn from past scans and prioritize the most effective seeds. In the visual example above, for example, if seed 5684 consistently finds Prompt Injection vulnerabilities across various APIs, the security tool can “learn” that this seed is highly effective and prioritize using it for future scans on similar targets.

• String Manipulation: Appending or prepending special characters like !@#$, <>.
• Data Type Fuzzing: Replacing an integer with a string, or a boolean with a number.
• Format String Attacks: Injecting format specifiers like %n, %s, or %x to test for format string vulnerabilities.

This dynamic approach can find novel vulnerabilities that a static word list could never anticipate by generating payloads in real time based on the application’s responses. 

How does API vulnerability detection work?

Let’s look at <seed 5684> with corresponding <payload B!>. The API Scanner sees the target API as a “black box”. It doesn’t need to understand the underlying logic of the API. It sends a series of requests (some with clean data, and some with the mutated, seeded payloads) and it analyzes the responses from the server, looking for anomalies.

The key to detection is response comparison. A clean request should yield a predictable response, while a malicious or fuzzed request might trigger an unexpected change. This could manifest as:

• A 500 Internal Server Error: A common indicator that an injected payload has caused an unhandled exception on the server.
• A 403 Forbidden or 401 Unauthorized: If an API returns one of these status codes for a request, it indicates that a user lacks the necessary permissions. The goal is to then send a specific payload that “flips” this response to a 200 OK. If successful, there is proof of a filter, authentication, or authorization bypass, confirming a broken access control vulnerability.
• Unexpected changes in response content: For example, an injected payload might cause the server to return database error messages or system file contents, or something as subtle as a deviating content length or longer response times.

The system flags these changes and presents them. This simple, response-based logic allows the tool to be highly effective and accurate without needing a deep understanding of the API’s internal workings. The engine takes this a step further by attempting to actually exploit the vulnerability, which reduces false positives and provides high-fidelity, actionable findings.

Conclusion

API security is moving away from static, reactive methods and towards a proactive, intelligent, and scalable model. Concepts like the seed number and mutation-based fuzzing, which can generate a virtually limitless attack surface to test against, help ensure that a security posture is as dynamic as the threats that organizations face. 

We can’t afford to only test for what is considered the norm. A truly effective security tool must go out of its way to find hidden parameters, unconventional routes, and unexpected states that would otherwise go unnoticed by most scanners. 

Try out our new API Scanner with dynamic fuzzing to see it in action. Book a demo here. 

FAQ

Q: What is the main problem with traditional API security scanners? A: One of the main problems is their reliance on static, finite word lists of known payloads, which makes them ineffective against new, mutated payloads that attackers are constantly developing.

Q: How does a seed number help with API fuzzing? A: A seed number deterministically generates a specific, reproducible unique set of payloads from a much smaller list, allowing for manageable and repeatable scans without needing to store a massive word list. This is why the new API scanner is able to achieve massive scale while ensuring reproducible results.

Q: What does Detectify look for to detect a vulnerability? A: It looks for anomalies in the server’s response after a fuzzed request, such as a 500 Internal Server Error, a 403 Forbidden status, or unexpected changes in the response content, compared to a clean request.