RESTler is the first stateful REST API fuzzing tool for automatically testing cloud services through their REST APIs and finding security and reliability bugs in these services. For a given cloud service with an OpenAPI/Swagger specification, RESTler analyzes its entire specification, and then generates and executes tests that exercise the service through its REST API.
RESTler intelligently infers producer-consumer dependencies among request types from the Swagger specification. During testing, it checks for specific classes of bugs and dynamically learns how the service behaves from prior service responses. This intelligence allows RESTler to explore deeper service states reachable only through specific request sequences and to find more bugs.
RESTler is described in these peer-reviewed research papers:
- RESTler: Stateful REST API Fuzzing (ICSE’2019)
- Checking Security Properties of Cloud Service REST APIs (ICST’2020)
- Differential Regression Testing for REST APIs (ISSTA’2020)
- Intelligent REST API Data Fuzzing (FSE’2020)
If you use RESTler in your research, please cite the (default) ICSE’2019 paper (BibTeX).
RESTler was created at Microsoft Research and is still under active development.
Setting Up RESTler
RESTler was designed to run on 64-bit machines with Windows or Linux.
Create a directory where you’d like to place the RESTler binaries:
Switch to the repo root directory and run the following Python script:
python ./build-restler.py --dest_dir <full path to restler_bin above>
Note: if you get nuget error NU1403 when building, a quick workaround is to clear your cache with this command
dotnet nuget locals all --clear
RESTler binary drops are coming soon.
RESTler runs in 4 main modes (in order):
- Compile: from a Swagger JSON or YAML specification (and optionally examples), generate a RESTler grammar. See Compiling.
- Test: execute quickly all of the endpoints+methods in a compiled RESTler grammar for debugging the test setup and compute what parts of the Swagger spec are covered. This mode is also called a smoketest. See Testing. To use custom test engine settings, see Test Engine Settings.
- Fuzz-lean: execute once every endpoint+method in a compiled RESTler grammar with a default set of checkers to see if bugs can be found quickly. See Fuzzing.
- Fuzz: bug hunting – explore a RESTler fuzzing grammar in smart breadth-first-search mode (deeper search mode) for finding more bugs. Warning: This type of fuzzing is more aggressive and may create outages in the service under test if the service is poorly implemented (e.g., fuzzing might create resource leaks, perf degradation, backend corruptions, etc.). See Fuzzing.
For a quick intro with simple examples, see this Tutorial.
To quickly try RESTler on your API, see Quick Start.
Bugs Found By RESTler
There are currently two categories of bugs found by RESTler.
- Error code: currently, any time a response with status code
500(“Internal Server Error”) is received, a bug is reported.
- Checkers: each checker tries to trigger specific bugs by executing targeted additional requests or sequences of requests at certain points during fuzzing, determined by context. Some checkers try to find additional 500s, while other checkers try to find specific logic bugs such as resource leaks or hierarchy violations. For a full description of checkers, see Checkers.
When a bug is found, RESTler reports bugs triaged in bug buckets, and provides a replay log that can be used to reproduce the bug (see Replay).
See also these Frequently Asked Questions.
If you’re interested in using RESTler at scale as part of your CI/CD pipeline, check out the REST API Fuzz Testing self-hosted service.