Fuzzing REST APIs paper

Software teams build APIs to move money, orders and tracking data between services. A new paper walks through what it takes to test those externally exposed REST endpoints automatically, and what still breaks in practice. (arxiv.org) Fuzzing here means sending large numbers of unexpected or malformed requests to an API to see which ones make it crash, leak data, or behave incorrectly. The paper reports on running EvoMaster, a search‑based fuzzing tool, inside Volkswagen’s engineering teams between 2023 and 2026 and summarizes what engineers actually needed to make fuzzing useful in production contexts. (arxiv.org) The authors catalog the common obstacles: APIs that insist on multi‑step sequences of requests, endpoints that require specific authentication or roles, and inputs that must follow complex semantic rules embedded in JSON bodies. Those constraints make simple random payloads useless; effective fuzzers must understand how responses produce tokens or IDs that feed subsequent requests. The paper describes concrete feature requests for fuzzers — better handling of authentication, stateful request sequencing, and richer oracles that detect logic and security faults rather than just HTTP 500 errors. (arxiv.org) Reproducibility and flakiness are a separate class of trouble. The authors and a companion study inspected thousands of failing tests produced by fuzzers and found many failures were flaky — dependent on timing, external services, or non‑deterministic state — which undermines CI pipelines and incident triage. They present an approach for detecting and mitigating flakiness and measure it across a corpus of APIs. That work shows that reducing noise is as important as finding new bugs when you want teams to trust automated negative testing. (arxiv.org) Security testing is also addressed. A related paper shows how fuzzing frameworks can be extended to run automated oracles for access‑policy violations and classic injection attacks, and to produce executable testcases when faults are found. Those techniques are implemented as EvoMaster extensions and validated on dozens of APIs. The result: fuzzing can move beyond crashing servers to proving privilege escalation and data‑exfiltration paths. (arxiv.org) For platform builders, the takeaway is practical. Integrate stateful fuzzing into an isolated test environment that mirrors production state, wire fuzzing artifacts into observability so failure traces include request sequences and exact tokens, and invest in de‑flaking so alerts point to real defects. The paper backs these engineering choices with a small user study and feedback from four Volkswagen APIs and eleven industry testing specialists. (arxiv.org) If you lead a platform team, these are architectural decisions: create service fixtures for seeded data, standardize authentication patterns to make test automation feasible, and surface fuzzing metrics in SLO dashboards (for example, number of unique security findings per week and mean time to reproduce). If you prefer the individual contributor path, focus on building fuzzing integrations that produce minimal, reproducible testcases and that plug into the incident workflow developers already use. Tooling matters: the space is populated by stateful fuzzers such as RESTler and EvoMaster; EvoMaster is the tool studied in these papers and is actively extended with security oracles. (github.com) The main paper and its companions are available on arXiv for immediate reading: “Fuzzing REST APIs in Industry: Necessary Features and Open Problems” (arXiv:2604.01759), posted April 3, 2026. (arxiv.org)