WuppieFuzz: Coverage-Guided, Stateful REST API Fuzzing

TL;DR

WuppieFuzz tackles the challenge of testing REST APIs with many endpoints by offering a coverage-guided, stateful fuzzer built on LibAFL and driven by OpenAPI specifications. It automates harness creation, seed-corpus generation, and a mutational workflow that uses coverage information to steer exploration, comparing white-box and black-box configurations on the Petstore API. The evaluation highlights how different schedulers balance exploration and exploitation, with white-box testing delivering faster initial coverage and richer feedback, while maintaining competitive endpoint discovery. The framework provides extensive reporting, dashboards, and a modular design to extend coverage agents and mutators, making it a practical tool for secure REST API development and testing.

Abstract

Many business processes currently depend on web services, often using REST APIs for communication. REST APIs expose web service functionality through endpoints, allowing easy client interaction over the Internet. To reduce the security risk resulting from exposed endpoints, thorough testing is desired. Due to the generally vast number of endpoints, automated testing techniques, like fuzzing, are of interest. This paper introduces WuppieFuzz, an open-source REST API fuzzer built on LibAFL, supporting white-box, grey-box and black-box fuzzing. Using an OpenAPI specification, it can generate an initial input corpus consisting of sequences of requests. These are mutated with REST-specific and LibAFL-provided mutators to explore different code paths in the software under test. Guided by the measured coverage, WuppieFuzz then selects which request sequences to send next to reach complex states in the software under test. In this process, it automates harness creation to reduce manual efforts often required in fuzzing. Different kinds of reporting are provided by the fuzzer to help fixing bugs. We evaluated our tool on the Petstore API to assess the robustness of the white-box approach and the effectiveness of different power schedules. We further monitored endpoint and code coverage over time to measure the efficacy of the approach.

Figures (7)

• Figure 1: Visualisation of the classification of possible settings based on the amount of (internal) knowledge of the SUT.
• Figure 2: Visualisation of the interaction between the SUT and WuppieFuzz, as well as the different components of the fuzzer. The LibAFL library is shown in orange. The OpenAPI interpreter and the different places where its results are used are shown in light orange.
• Figure 3: Example graph, showing the relations between API endpoints through the use of resources (dark boxes) created by other endpoints.
• Figure 4: Example API endpoint dependency graph as reported by WuppieFuzz.
• Figure 5: Example of information displayed on the dashboard.