ffufplus: When Shell Scripts Make Better Security Tools Than Frameworks

Hook

The most starred web fuzzing automation tool on GitHub doesn't use Python, Go, or Rust—it's a Shell script that proves sometimes the simplest abstraction wins.

Context

Web application security testing involves running the same ffuf commands dozens of times per engagement: enumerate directories, find files with different extensions, test for backup files, probe for configuration leaks, and discover API endpoints. Each requires tweaking wordlists, adjusting matchers and filters, and manually correlating results. Security researchers end up with terminal history full of similar ffuf invocations, each slightly different, often forgetting which filter values worked best or which wordlist combination yielded results.

ffuf itself is intentionally minimal—a Unix philosophy tool that does one thing exceptionally well. But this minimalism creates friction in real-world workflows. You need to remember that .git/config requires different matching than admin.php, that you should filter 404s differently than redirects, and that certain wordlists work better for API endpoints versus static files. ffufplus emerged from this gap: the recognition that 80% of web fuzzing follows predictable patterns that shouldn't require memorizing command-line incantations.

Technical Insight

ffufplus is essentially a workflow compiler that translates high-level fuzzing intent into orchestrated ffuf executions. The Shell script architecture makes this transparent—you can read exactly what it does without reverse-engineering binaries or navigating framework abstractions.

The core design pattern is sequential fuzzing with progressive refinement. Instead of one massive wordlist run, ffufplus chains targeted scans: first broad directory discovery, then extension-based file enumeration, followed by backup file detection and configuration leak probing. Each stage uses its results to inform the next, building a decision tree of what to probe deeper.

Here's how a typical ffufplus workflow translates to actual ffuf commands:

# Stage 1: Directory discovery with common paths
ffuf -u https://target.com/FUZZ -w common-dirs.txt \
  -mc 200,204,301,302,307,401,403 \
  -fc 404 -o dirs.json

# Stage 2: Extension bruteforce on discovered paths
while read dir; do
  ffuf -u https://target.com/${dir}FUZZ \
    -w extensions.txt \
    -mc 200,204,301,302 \
    -fc 404 -o "${dir}_files.json"
done < dirs.json

# Stage 3: Backup file detection
ffuf -u https://target.com/FUZZ \
  -w backup-patterns.txt \
  -mc 200,204 \
  -fs 0 -o backups.json

The script's intelligence lies in its filtering heuristics. Rather than relying on users to know that -fc 404 isn't enough (some servers return 200 for missing files), ffufplus automatically adds size-based filtering (-fs) and combines multiple filter strategies. It knows that a 301 redirect to /login is interesting but a 302 to /error probably isn't.

Another clever pattern is wordlist selection automation. Instead of making users choose between SecLists' 40+ directory wordlists, ffufplus maintains an opinionated hierarchy: start with raft-small-directories.txt for speed, escalate to directory-list-2.3-medium.txt if initial results look promising, and only use comprehensive lists for targeted deep-dives. This mirrors how experienced researchers actually work.

The Shell implementation also enables trivial customization. Want to add Nuclei scanning on discovered endpoints? Append a template scan after the fuzzing stages. Need to integrate with your organization's ticketing system? Add a webhook call. The script becomes a scaffold for building custom reconnaissance pipelines without learning a framework's extension API.

Post-processing is where ffufplus adds substantial value over raw ffuf. It deduplicates results (ffuf might find /admin and /admin/ as separate hits), normalizes output formats, and generates human-readable reports alongside machine-parseable JSON. The script also handles edge cases like servers that return different response sizes for the same 404, which would normally require manual -fs adjustment after initial runs.

Gotcha

The transparency of Shell scripts cuts both ways. While you can easily read what ffufplus does, the lack of proper documentation means you must read the source to understand its behavior. There's no --help output explaining which wordlists it uses, what filtering logic applies, or how to customize scan intensity. You're essentially auditing someone else's workflow decisions codified in bash.

Error handling is minimal because Shell scripts lack robust exception mechanisms. If ffuf isn't in your PATH, or if wordlist files are missing, you'll get cryptic errors rather than helpful guidance. The script assumes a working ffuf installation with specific wordlists in expected locations—there's no dependency checking or graceful degradation. Network issues, rate limiting, or WAF blocks that would benefit from retry logic or backoff strategies just fail silently. For production security assessments where you need audit trails and reliable execution, this fragility is problematic. You also lose ffuf's built-in rate limiting and threading controls, which are hardcoded in the wrapper rather than exposed as configurable parameters.

Verdict

Use if: You run the same ffuf workflows repeatedly and want to codify your personal reconnaissance methodology without framework overhead. You're comfortable reading Shell scripts and modifying them for your environment. You treat this as a starting template rather than a finished product, and you're already experienced enough with ffuf to understand what the wrapper is automating. You value transparency and hackability over polish and documentation. Skip if: You need production-ready tooling with proper error handling, logging, and maintainability. You're new to web fuzzing and want to learn the underlying concepts rather than abstract them away. You require configurable parameters without editing source code, or you work in environments where running untrusted Shell scripts against production systems is forbidden. You'd be better served by writing your own automation that matches your exact workflow or using ffuf directly until you've internalized which patterns you actually repeat.