API security is no longer just a concern; it’s a critical priority for businesses. With APIs serving as the backbone of modern applications, they’ve become a primary target for attackers. While automated security testing tools help detect vulnerabilities, their limitations leave organizations exposed to evolving threats. Here’s where Threat Replay Testing (TRT) comes into play.
This cutting-edge approach flips the script, allowing security teams to turn real-world attack attempts into valuable insights for protecting API infrastructure. Below, we’ll break down what Threat Replay Testing is, how it works, and why it’s a game-changer for DevOps engineers, security professionals, and API developers.
To appreciate the value of Threat Replay Testing, it’s important to understand the limitations of conventional API security testing. Today, most organizations rely on automated security testing tools to scan their APIs. While broadly effective, these tools have limitations that could result in missed API vulnerabilities.
Most organizations rely on automated tools to scan for vulnerabilities. While useful, these tools mainly test exposed endpoints and apply rule-based testing methods using predefined scenarios. This creates significant blind spots since:
Attackers don’t follow a script. They use adaptive techniques to bypass existing defenses. Static testing methods fail to replicate this dynamic behavior, leaving organizations vulnerable to innovative exploitations.
Threat Replay Testing addresses these shortcomings by leveraging real-world data for dynamic testing, ensuring relevance and effectiveness against current attack methods.
Threat Replay Testing bridges the gap between theoretical security testing and real-world response. Unlike traditional methods that rely on predefined testing scenarios, TRT leverages real attack data to simulate potential vulnerabilities.
Essentially, TRT identifies malicious requests intercepted by your security systems, analyzes their characteristics, and uses them to generate simulated test attacks. These test attacks mimic the original threats in a controlled and safe environment, enabling organizations to better understand their system vulnerabilities and proactively secure them before attackers can exploit them.
By creating tests from real-life data, TRT evolves with attackers, offering dynamic defenses against constantly changing threats.
We must break down its process step by step to understand TRT’s capabilities. The following section illustrates how this method effectively identifies and mitigates vulnerabilities.
TRT begins by collecting malicious request data from the Wallarm Filtering Node (or similar tools). These are requests flagged as potentially harmful in your production system. For instance, a detected SQL injection attack (SQLi) targeting a login endpoint provides the raw data that TRT uses to formulate test cases.
This initial data includes:
Using the collected data, TRT generates 100-150 test requests. Each is designed to target the same vulnerabilities as the captured malicious request but with a variety of payloads. These generated payloads simulate real attack behaviors while omitting any truly harmful code or syntax, ensuring the safety of your systems.
For example, if the original malicious request attempted to manipulate the user parameter for SQL injection, test cases might include variations like:
https://staging.example.com/login?user=UNION SELECT username, version() --https://staging.example.com/login?user=1' OR SLEEP(10)--https://staging.example.com/login?user=1")+AND+PG_SLEEP(5)-- The replayed test requests are never sent to production systems. Instead, they are safely redirected to staging or development environments, where they cannot disrupt your live operations. This ensures that the simulated attacks remain purely exploratory and pose no risk to end-users or active applications.
The module evaluates how your APIs respond to these simulated attacks. It identifies key vulnerability indicators, such as unexpected behaviors, server errors, or responses that suggest the attempt was partially successful.
For every identified weakness, TRT logs details into a vulnerability dashboard like the Wallarm Console UI. This actionable data empowers your security team to act quickly and effectively to close gaps.
The following diagram demonstrates how the TRT works:
For detailed instructions on how to enable Threat Replay Testing and create test policies, please review the product documentation.
As APIs grow in number and importance, TRT can be the essential security measure that ensures APIs are free from vulnerabilities that attackers could exploit.
Now let’s jump in to see an example how TRT would work in reality. The Threat Replay Testing module is designed to create test requests in the most secure manner possible, featuring the following key characteristics:
Cookie, Authorization: Basic, and Viewstate are excluded from replayed requests. Further, as guided by the custom authentication headers and masking rule, any additional headers may be adapted or removed as required.Step 1:Consider the following real-world-like GET request initially detected by the Wallarm filtering node and uploaded to the Cloud:
https://prod.example.com/login?user=UNION SELECT username, password From the request, the module learns the following details:
https://prod.example.com/loginUNION SELECT username, password payload)usertoken=IyEvYmluL3NoCg (it is probably used by the application to authenticate the user)Step 2:Leveraging this data, the module crafts a series of test requests. These requests focus on potential SQL injection vulnerabilities using varied payloads, such as:
https://staging.example.com/login&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm
https://staging.example.com/login&user=1+AND+SLEEP(10)--+wlrm
https://staging.example.com/login&user=1);SELECT+PG_SLEEP(10)--
https://staging.example.com/login&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm
https://staging.example.com/login&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10))
https://staging.example.com/login&user=%23'%23\x22%0a-sleep(10)%23
https://staging.example.com/login&user=1';+WAITFOR+DELAY+'0code:10'--
https://staging.example.com/login&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm
https://staging.example.com/login&user=SLEEP(10)/*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/ By implementing a TRT approach, you empower your organization with a robust, proactive security mechanism. Here’s how it adds value to your security strategy:
By implementing TRT, organizations can ensure they keep pace with rapidly evolving attackers and attack techniques. It is the future of API security, ensuring that real-world attack intelligence drives security improvements and facilitates a transformative shift from passive protection to active threat discovery. By embracing TRT, companies can turn attackers into valuable security assets, learning from their tactics and using their attacks to enhance their security posture.
APIs are essential, dynamic, and critical to modern application infrastructure, but they also pose significant risks. Threat Replay Testing is a core innovation that transforms traditional security testing into adaptive, proactive defense mechanisms. With TRT, enterprises can stay ahead of attackers and ensure their APIs are secure, scalable, and resilient.
At Wallarm, we deliver advanced unified API security solutions that are trusted by some of the world’s most innovative companies. From real-time protection to Threat Replay Testing, our platform offers an all-in-one approach to API security. Want to see how TRT can protect your APIs? Try Wallarm’s Threat Replay Testing today.
Is an AI-to-AI attack scenario a science fiction possibility only for blockbusters like the Terminator…
Lefteris Tzelepis, CISO at Steelmet /Viohalco Companies, was shaped by cybersecurity. From his early exposure…
This is a predictions blog. We know, we know; everyone does them, and they can…
The attack landscape has been dynamic following the disclosure of the React Server Components RCE…
As the year draws to a close, it’s worth pausing to look back on what…
On December 3, 2025, React maintainers disclosed a critical unauthenticated remote code execution (RCE) vulnerability…