Fuzzing a web API means sending malformed or unexpected requests to a running service and watching the responses. Compared with parser fuzzing it is slower, has no coverage feedback by default, and can damage shared systems. Do it against a staging copy, with test data, and decide in advance what counts as a bug.
What OWASP says
OWASP describes fuzzing as feeding a program unexpected, malformed or semi-malformed inputs. For web applications it names the attack surface as the app's inputs and outputs: URLs, forms, user-generated content and RPC requests. It also lists protocol fuzzers that act as proxies and alter and replay requests, and injection style checks using inputs like quotes or SQL commands.
How it differs from parser fuzzing
- No in-process coverage feedback. A parser fuzzer sees which lines ran. A network fuzzer usually sees only the response.
- Much lower speed. Every input is a network round trip, so you try thousands, not millions.
- State and side effects. Requests can create accounts, send emails, charge cards, or fill a database.
- Authentication. A fuzzer that cannot log in tests only the login page.
Scope it safely
- Use a staging environment with test data, never production.
- Use test credentials with the least privilege that covers the endpoints.
- Turn off real outbound actions: email, payments, webhooks.
- Set rate limits on the fuzzer so you do not mistake an outage for a finding.
- Get written approval if the target is a service owned by someone else. Do not fuzz what you do not own.
What to send
Start from your API description, such as an OpenAPI file, so requests are valid enough to reach handlers. Then mutate: wrong types, missing fields, huge strings, nested objects, odd encodings, boundary numbers, and unexpected methods. Keep a set of known good requests as seeds.
Decide what counts as a failure
Without a crash signal you must define one:
- Server errors, the 500 class of responses.
- Responses that take far longer than normal.
- Stack traces or internal details in the body.
- Accepted input that should have been rejected, such as a negative quantity.
- Differences in behavior across users, a sign of authorization problems.
The last is where manual review still wins. A fuzzer cannot know that user A should not see user B's record unless you give it two users and a rule.
Combine with in-process fuzzing
For handlers that parse complex bodies, extract the parsing function and fuzz it with a coverage-guided harness. Use network fuzzing for the behavior only visible end to end.
Try it yourself
Open the API security scan demo and look at what a scan checks and reports. Compare that with what a fuzzer cannot know on its own, such as who should see which record.
Click through it at your own pace, or open it full screen.
Quick check
Is it fine to fuzz a third party API?
Not without permission. Fuzzing can disrupt a service and may break its terms. Test your own systems or get written approval.
Why did my API fuzzer find nothing?
Common reasons are failed authentication, invalid requests that never reach handlers, or no definition of failure. Check what the fuzzer actually reached.
Sources
Last reviewed: 19 October 2026.
