API Fuzzing with RESTler

Purpose

Run Microsoft RESTler for stateful, grammar-driven REST API fuzzing: producer-consumer request sequences that surface 500-class crashes, authentication bypasses, resource leaks, injection, and state-dependent bugs that single-request testing misses. Destructive sequences are part of the methodology and are governed by the runtime policy, not by this skill.

Preconditions

• OpenAPI/Swagger spec (v2 or v3) for the target API
• RESTler installed (github.com/microsoft/restler-fuzzer) with Python 3.12+ and .NET 8
• Working auth (refresh command if tokens expire mid-run)
• Authorization: RESTler creates, modifies, and deletes resources aggressively

Attack Surface Signals

• Any documented OpenAPI spec (from recon, swagger.json, v2/v3 api-docs)
• APIs with object dependencies: create → update → delete chains
• Endpoints where invalid input handling matters (500s, injection, auth bypasses)

Methodology

Step 1: Compile the Grammar

restler compile --api_spec tmp/openapi.json

Inspect Compile/grammar.py for unresolved producer-consumer dependencies, endpoints that never get inputs are silently untested.

Step 2: Configure Auth

Save the following JSON as restler_user_settings.json. Supply a reviewed refresh_token.py implementing the test application's actual login protocol. RESTler requires a metadata line followed by complete token header lines; a bare access-token string is not valid refresh output. For example:

{u'app1': {}}
Authorization: Bearer FIXTURE_TOKEN_VALUE

{
  "authentication": {
    "token": {
      "token_refresh_cmd": "python3 refresh_token.py",
      "token_refresh_interval": 1800
    }
  }
}

Verify the auth header is LIVE before trusting a clean run: a broken refresh command makes RESTler fuzz as anonymous and "find nothing".