Fuzzing

Fuzzing in Dochia provides continuous, randomized testing using mutators rather than pre-defined playbooks. This approach allows for exploratory testing and discovery of unexpected vulnerabilities through random mutations of request data.

What is Fuzzing?

Fuzzing is a testing technique that involves sending random, unexpected, or invalid data to your API to discover vulnerabilities, crashes, or unexpected behaviors that structured testing might miss.

Unlike structured playbooks that test specific scenarios, fuzzing applies 28 different mutators randomly to generate unpredictable test cases, making it ideal for discovering edge cases and unknown vulnerabilities.

Available Fuzzing Resources

Fuzzing Overview

Complete guide to fuzzing with Dochia - This is your main resource for fuzzing documentation.

What's covered:

• All 28 mutators with detailed descriptions and use cases
• Complete CLI reference with all flags and options
• Fuzzing strategies for different scenarios (discovery, targeted, security)
• Best practices and safety considerations
• Advanced examples with real command patterns
• Result interpretation and analysis techniques

Custom Mutators

Advanced guide for creating custom mutation strategies when the built-in mutators aren't sufficient.

What's covered:

• Understanding mutator architecture
• Creating domain-specific mutators
• Advanced mutation techniques
• Integration with existing workflows

When to Use Fuzzing

Fuzzing vs Playbooks

Aspect	Playbooks	Fuzzing
Approach	Structured, predefined test cases	Random, continuous mutations
Coverage	Comprehensive, systematic	Exploratory, unpredictable
Use Case	Validation, compliance testing	Vulnerability discovery
Duration	Fixed test suite	Continuous until stopped
Targeting	All endpoints and methods	Single endpoint/method

Ideal Scenarios

🔍 Discovery Testing

• Finding unknown vulnerabilities
• Exploring edge cases and boundary conditions
• Security research and penetration testing

🔄 Continuous Monitoring

• Long-running security monitoring
• Regression testing for new vulnerabilities
• Production safety validation

⚡ Quick Validation

• Pre-deployment security checks
• Developer workflow integration
• Rapid vulnerability assessment

Getting Started

Basic Fuzzing Command

⚠️ REQUIRED ARGUMENTS: The dochia fuzz command requires at least one stop condition (--stop-XX) and at least one match condition (--match-XX) to be specified.

# Simple fuzzing execution (with required conditions)
dochia fuzz --contract api.yml --server https://api.example.com \
  --path /api/users --http-method POST \
  --stop-after-time-in-sec 300 \
  --match-response-codes 500

Quick Examples

# Time-limited fuzzing
dochia fuzz -c api.yml -s https://api.example.com -p /users -X POST \
  --stop-after-time-in-sec 1800 \
  --match-response-codes 500

# Mutation-limited fuzzing  
dochia fuzz -c api.yml -s https://api.example.com -p /users -X POST \
  --stop-after-mutations 1000 \
  --match-input

# Rate-limited fuzzing (production-safe)
dochia fuzz -c api.yml -s https://api.example.com -p /users -X POST \
  --max-requests-per-minute 60 \
  --stop-after-time-in-sec 600 \
  --match-response-codes 500

Key Concepts

Mutators

Dochia includes 28 built-in mutators organized into categories:

• String and Text Mutations (5 mutators)
• Unicode and Special Characters (8 mutators)
• Numeric Mutations (5 mutators)
• Case Expansion Testing (4 mutators)
• Structure and Format (6 mutators)

See Fuzzing Overview for complete mutator details.

Execution Modes

• Time-based: Run for a specific duration
• Mutation-based: Stop after a number of mutations
• Continuous: Run until manually stopped
• Targeted: Focus on specific endpoints or methods

Result Analysis

Fuzzing generates detailed reports showing:

• Response code patterns and anomalies
• Performance and timing issues
• Input reflection and information leakage
• Security vulnerabilities and edge cases

Integration Patterns

Development Workflow

# Quick pre-commit check
dochia fuzz -c api.yml -s http://localhost:8080 -p /api/endpoint -X POST \
  --stop-after-time-in-sec 300 \
  --match-response-codes 500

CI/CD Pipeline

- name: Security Fuzzing
  run: |
    dochia fuzz -c openapi.yml -s ${{ secrets.STAGING_URL }} \
      -p /api/critical-endpoint -X POST \
      --stop-after-time-in-sec 1800 \
      --match-response-codes 500

Continuous Monitoring

# Daily security fuzzing
dochia fuzz -c api.yml -s https://api.example.com \
  -p /api/users -X POST \
  --stop-after-time-in-sec 7200 \
  --max-requests-per-minute 30 \
  --match-response-codes 500

Best Practices

Safety First

• Start with non-production environments
• Use conservative rate limits
• Monitor server health during fuzzing
• Have rollback procedures ready

Effective Fuzzing

• Combine with playbook testing for comprehensive coverage
• Use appropriate match criteria to catch relevant issues
• Analyze results systematically to identify patterns
• Iterate based on findings to improve coverage

Next Steps

1. Start with Fuzzing Overview - Complete fuzzing documentation
2. Try the fuzz command - CLI reference and examples
3. Explore Custom Mutators - Advanced techniques
4. Advanced Integration - Enterprise patterns and CI/CD

Need Help?

• Fuzzing Overview - Complete fuzzing guide with all details
• CLI Reference - Command documentation
• Troubleshooting - Common issues and solutions
• Community - Get help and share experiences