What is fuzz testing?
Fuzz testing (fuzzing) is an automated testing technique that sends invalid, unexpected, or random data to an API and monitors for crashes, hangs, memory leaks, or security violations. The goal: **find bugs that humans wouldn't think to test for**.
While functional tests validate expected behavior, fuzzing explores the chaos zone — what happens when you send 10MB of data to a field expecting 50 characters? SQL injection in the email field? Unicode emojis in a numeric field? Fuzzing finds these edge cases automatically.
Why fuzzing matters for API security
Most security vulnerabilities don't come from missing features — they come from **unexpected input handling**. A single unvalidated field can enable SQL injection, command injection, or buffer overflow attacks.
Real-world fuzzing discoveries
- Heartbleed (OpenSSL): Found by fuzzing. Allowed attackers to read server memory.
- Cloudflare Cloudbleed: HTML parser crashed on malformed input, leaking customer data.
- Google Chrome: Over 16,000 bugs found via continuous fuzzing.
- Microsoft Edge: Found 3,000+ security bugs before release using fuzzing.
Types of fuzz testing
| Fuzzing Type | What It Does | Use Case |
|---|---|---|
| Random fuzzing | Completely random data (gibberish) | Catch basic crashes and validation gaps |
| Mutation-based | Takes valid input, mutates it slightly | Test edge cases near valid boundaries |
| Generation-based | Generates data based on schema/grammar | Protocol-aware testing (JSON, XML) |
| Smart fuzzing | Uses feedback loops to guide inputs | Deep code path exploration (AFL, libFuzzer) |
| Security fuzzing | Injects known attack patterns (SQLi, XSS) | Simulate real attack vectors |
What fuzzing finds in APIs
1. Input validation failures
- Missing length checks → buffer overflow
- Type confusion → integer overflow
- Missing sanitization → injection attacks
2. Injection vulnerabilities
- SQL injection:
' OR '1'='1 - NoSQL injection:
{"$gt": ""} - Command injection:
; rm -rf / - LDAP injection:
*)(uid=*))(|(uid=*
3. Memory safety issues
- Null pointer dereferences
- Use-after-free bugs
- Buffer overflows
- Memory leaks from malformed requests
4. Business logic bypasses
- Price manipulation (
price: -100) - Authorization bypass via ID tampering
- Rate limit evasion
How to fuzz test APIs in Flasqo
-
Navigate to Fuzz Testing
Go to Testing Types → Fuzz Testing → Launch -
Enter API endpoint
Example:https://api.yourapp.com/users
Select HTTP method:POST,PUT, orPATCH -
Define request schema
Paste example valid request body:
{ "email": "user@example.com", "age": 25, "role": "user" }Flasqo auto-detects field types (string, number, boolean) -
Configure fuzzing parameters
• Intensity: Low (100 tests), Medium (1000 tests), High (10,000 tests)
• Fuzz types: Random, SQL injection, XSS, buffer overflow, type confusion
• Fields to fuzz: All fields or specific ones -
Set safety limits
• Max payload size: Prevent DoS (default: 1MB)
• Rate limit: Requests per second (default: 10/sec)
• Timeout: Stop if response takes too long -
Run fuzz campaign
Click "Start Fuzzing"
Flasqo sends thousands of malformed payloads and monitors responses -
Review discovered bugs
• ❌ Crashes (500 errors, timeouts)
• ⚠️ Unexpected behavior (wrong status code)
• 🔓 Security issues (SQL errors, stack traces)
• Click any issue to see the exact payload that triggered it -
Export findings
• Download PDF report with all vulnerabilities
• Share with security team
• Integrate with bug tracker (Jira, GitHub Issues)
Common fuzzing payloads
String fuzzing
"" # Empty string
null # Null value
" ".repeat(10000) # Extremely long string
"" # XSS attempt
"' OR '1'='1" # SQL injection
"\x00\x00\x00" # Null bytes
"../../../../etc/passwd" # Path traversal
"${7*7}" # Template injection
Number fuzzing
-1 # Negative number
0 # Zero
2147483647 # Max 32-bit int
2147483648 # Overflow 32-bit int
999999999999999 # Huge number
0.00000001 # Tiny float
NaN # Not a number
Infinity # Infinite value
Boolean fuzzing
"true" # String instead of boolean
1 # Number instead of boolean
null # Null instead of boolean
[] # Array instead of boolean
{} # Object instead of boolean
Fuzzing in CI/CD pipelines
Automate fuzzing to catch vulnerabilities before deployment:
GitHub Actions example
name: Security Fuzzing
on:
pull_request:
branches: [main]
jobs:
fuzz:
runs-on: ubuntu-latest
steps:
- name: Run API fuzz tests
run: |
curl -X POST https://api.flasqo.com/fuzz \
-H "Authorization: Bearer ${{ secrets.FLASQO_API_KEY }}" \
-d '{
"base_url": "https://staging.api.yourapp.com",
"endpoints": ["/users", "/payments", "/auth/login"],
"intensity": "medium"
}'
- name: Check for critical vulnerabilities
run: |
if grep -q "CRITICAL" fuzz-report.json; then
echo "Critical vulnerabilities found - blocking merge"
exit 1
fi
Best practices for API fuzzing
1. Start small, scale up
Begin with 100-1000 test cases per endpoint. If no bugs surface, increase to 10,000+. Don't fuzz everything at once — focus on high-risk endpoints first (auth, payments, user input).
2. Combine fuzzing with validation
Fuzzing finds crashes. Manual review determines if they're exploitable. Not every 500 error is a security issue, but every SQL error message is.
3. Monitor server health during fuzzing
Watch CPU, memory, and disk usage. A gradual memory increase suggests a memory leak. Sudden CPU spikes might indicate algorithmic complexity attacks.
4. Fuzz authentication and authorization separately
Test both authenticated and unauthenticated requests. Many APIs crash differently when auth headers are malformed.
5. Save payloads that trigger bugs
Create regression tests from discovered bugs. If fuzzing finds that email: null crashes your API, add that as a permanent test case.
Find vulnerabilities before hackers do
Run automated fuzz tests on your API in minutes. No security expertise required.
Start Fuzzing FreeFuzzing vs other security testing
| Method | Speed | Coverage | Expertise Required |
|---|---|---|---|
| Fuzz testing | Fast (automated) | Broad (random inputs) | Low |
| Penetration testing | Slow (manual) | Deep (strategic) | High |
| Static analysis | Fast (automated) | Code-level only | Medium |
| Vulnerability scanning | Fast (automated) | Known CVEs only | Low |
Frequently asked questions
What is the difference between fuzz testing and penetration testing?
Fuzz testing is automated and focuses on finding crashes and unexpected behavior by sending malformed input. Penetration testing is manual, strategic exploitation by security experts who chain vulnerabilities together. Fuzzing finds the bugs; pentesters exploit them.
Can fuzz testing break my production environment?
Yes, if you run it against production. Fuzzing can trigger DoS conditions, fill databases with garbage, or crash services. Always fuzz in staging or test environments. Use rate limiting and monitoring if you must test production.
How long should a fuzz testing campaign run?
Most critical bugs surface within the first hour. Run fuzzing for at least 24 hours per API endpoint to catch deeper edge cases. Security-critical APIs should run continuous fuzzing as part of CI/CD.
Does fuzzing find all security vulnerabilities?
No. Fuzzing finds input validation bugs, crashes, and injection vulnerabilities. It won't find business logic flaws (e.g., "users can view other users' data") or authentication bypasses that require multi-step workflows. Combine fuzzing with manual pentesting.
What should I do when fuzzing finds a crash?
1) Reproduce the crash with the exact payload. 2) Check logs for stack traces or error messages. 3) Determine if it's exploitable (does it leak data? allow code execution?). 4) Fix the validation bug. 5) Add the payload as a permanent regression test.