Ahead of Nordic APIs Summit 2026, we check in with speaker Andrea Arcuri on how fuzz testing for APIs is evolving.

“You cannot really check security properties if all your HTTP calls fail with a 4xx because your techniques can’t generate the right test data to pass the first layer of input validation,” answers Andrea Arcuri when asked where he sees fuzz testing going in the next year. Automated fuzz testing is just one of the ways he anticipates software and API testing evolving, as LLMs and automated environments become more sophisticated.

The evolution of fuzz testing for APIs is the topic of Verifying REST API Security with Fuzzing, Arcuri’s upcoming presentation at Nordic APIs Summit 2026. Ahead of his talk, we caught Arcuri to discuss his experience as a professor of software engineering at Kristiania University of Applied Sciences and Oslo Metropolitan University and decades of working with fuzz testing.

On API Fuzz Testing With Prof. Andrea Arcuri

1. For anyone who might not have encountered the term before, what is fuzz testing?

At a high level, fuzz testing is an automated technique aimed at generating test cases to find faults in existing software. The term originally comes from the security literature, but it has been used in several different contexts, for example, in software engineering, with different levels of nuance for its exact meaning (for example, based on how tests are generated and what kind of faults it aims at finding). I simply use the term “fuzz testing” as a shorthand for “automated test case generation.”

2. You’ve been working with software testing since at least 2007. What have been some of the biggest changes you’ve seen in software testing in the last 20 years? Has anything stayed the same?

If I have to name the biggest change, it is definitely Docker. The possibility of easily spinning up databases and other services directly from the test case scripts was a major game changer. Recently, LLMs have brought automated test generation to the spotlight. The possibility of generating test cases automatically has been available for decades (with different levels of success), but LLMs are definitely what made it now popular to a bigger audience (albeit, at times, with worse results than specialized tools for this task).

3. You’ve been working with fuzz testing for decades, but you’ve only been fuzzing APIs for six or seven years. What inspired you to move into fuzz testing APIs? How is fuzz testing APIs different from other types of software or digital tools?

Throughout my career, I moved between academia and industry. In my last job as a testing consultant at Telenor (a telecommunications company), I was paid by the hour to manually write REST Assured test cases for some of its APIs. When I came back to academia, working on such a topic was a natural choice.

At that time, most of the research work in the literature was focused on “unit testing.” “System testing” of APIs, which includes databases, was nearly an unexplored field in the research community.

4. You created an open source tool for fuzz testing called EvoMaster. First of all, what inspired you to create EvoMaster? How is it different from other fuzz testing tools out there?

To do research, I need to develop novel techniques that push forward the current state-of-the-art. To make sure those techniques actually work and are successful, I need to run empirical studies. Building a tool that can actually be successfully used on many different APIs is a necessity. As this is research funded by taxpayers, all of my work is open source. When I started building EvoMaster in 2016, there was no existing open source fuzzer for REST APIs.

5. In last year’s talk at Nordic APIs Platform Summit, you shared some of your favorite open source fuzz testing tools. Do you have any tools for verifying REST API security with fuzzing that you like? What do you like about them?

API security is a very important topic. And that is the reason why, in the last couple of years, I have focused on adding security checks in EvoMaster (for example, BOLA, SQLi, and XSS). Regarding other existing tools, in academia, many of those are just discontinued prototypes. One popular open source tool was Astra, but unfortunately, it seems it is now no longer maintained. There are a few companies out there that provide commercial tools for API security, but in academia, we usually do not deal with commercial tools (for a lot of different reasons, for example, cost and EULAs). So, I cannot really tell you how good or bad they are.

6. When you gave an expanded version of your talk about fuzz testing web APIs last year at TestCon, AI was all the rage. “Not just LLMs, but other techniques like neural networks, reinforcement learning, and genetic algorithms,” as you put it at the time. Is this still true in 2026? Have any of these approaches become more important in the last year? Have any fallen by the wayside?

Yes, it is still true in 2026. LLMs are extremely good when dealing with natural language (for example, “description” entries in OpenAPI schemas), but, for many other tasks, they are very inefficient compared to specialized algorithms.

7. Your most recent paper published on arXiv, “Using OAI Overlay to Enhance REST API Fuzzing,” the abstract talks about how testing software often has to provide extra information to steer a fuzzer in the right direction. An OpenAPI Overlay file is mentioned as a possible solution for this problem. First, can you briefly describe what an OpenAPI Overlay file is? How do they help fuzzers work like they should?

OpenAPI Overlay is a standard to specify sequences of transformations on OpenAPI schema files. With such Overlay files, you can specify how to add, remove, and modify nodes in the schema. One possible application is to add “examples” entries in the schema, with values that are specific for the used testing environment (for example, existing IDs of users in the databases). As a tester, you do not want to add those entries directly in the schema, as, each time you get a new updated version of the schema to test, you would need to manually redo all the modifications. Overlay solves this problem, as I show in that paper with a study in five different companies worldwide (from Germany to China).

Ideally, a fuzzer would not need any manual help and be fully automated. We are not there yet, though. But, as fuzzers can exploit the data in the “examples” entries, this enables the testers to provide such extra info in a standard, fuzzer-agnostic way (in other words, that would work also for other fuzzers besides EvoMaster).

8. You teach software engineering as well as working as a researcher and developer. What have been some exciting innovations you’ve seen in fuzz testing or API security? Where do you see this tech going in the next six to 12 months?

In research, there are new exciting improvements every year. It is hard to keep track of all the innovations that keep on coming! I do not expect any major, drastic change in the next six to 12 months. What I expect, though, is a more widespread use in industry.

Regardless of whether you want to use an open source tool or a commercial one, there are many options available today. Still, many practitioners might not know about them, besides trying out some prompts to get an LLM generating API tests. It will be interesting to see how this will change and what will happen when those automated techniques become more mainstream.

When it comes to academic research in REST API fuzzing, most of the work has been focused on “functional” testing. You cannot really check security properties if all your HTTP calls fail with a 4xx because your techniques can’t generate the right test data to pass the first layer of input validation. But, as techniques get better and better, security testing is a topic that is getting more traction in the literature in the last couple of years. More can be expected in the next six to 12 months, especially when specialized fuzzers can be smartly integrated with LLMs.