Use when you need authorized web fuzzing with ffuf for content discovery, endpoint enumeration, virtual host or parameter fuzzing, response filtering, and structured result capture while preserving upstream workflow intent, copied support files, and provenance before review, merge, or handoff.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
ffuf-claude-skill-v2
description
Use when you need authorized web fuzzing with ffuf for content discovery, endpoint enumeration, virtual host or parameter fuzzing, response filtering, and structured result capture while preserving upstream workflow intent, copied support files, and provenance before review, merge, or handoff.
This skill preserves the upstream ffuf-focused workflow while making it operational for real execution.
Use it when you need to run or guide authorized web fuzzing with ffuf: content discovery, directory or file busting, endpoint enumeration, virtual host fuzzing, parameter fuzzing, header-based fuzzing, or wordlist-driven probing. It is also appropriate when the operator must keep provenance visible and preserve upstream workflow intent, copied support files, and review context before merge or handoff.
This skill does not authorize scanning by itself. Only use it against targets you are explicitly permitted to test.
When to Use
Use this skill when:
You need ffuf-based discovery against a web application or HTTP service.
The user asks for directory, file, endpoint, parameter, header, or vhost fuzzing.
You need to move from a noisy first pass to controlled filtering and matching.
You need reproducible ffuf commands and machine-readable output such as JSON or JSONL.
You must preserve upstream workflow intent and provenance in the deliverable.
Do not use this skill when:
The target is not clearly authorized for testing.
The task requires exploitation, credential attacks, or unsafe load generation outside the approved scope.
A browser-driven workflow is more appropriate than wordlist-based HTTP fuzzing.
Workflow
Confirm authorization and scope
Verify the target hostnames, ports, paths, rate limits, and time window.
Confirm whether recursive discovery, subdomain/vhost probing, or parameter fuzzing is allowed.
Prefer the narrowest test that satisfies the request.
Establish a low-noise baseline
Inspect one or more normal responses first with curl or an equivalent safe HTTP request.
Note common status codes, body sizes, words, and line counts for missing resources or redirects.
Identify whether the application returns soft 200s, wildcard routing, CDN error templates, or enforced redirects.
Choose a focused ffuf mode
Path discovery: fuzz FUZZ in the URL path.
File/extension discovery: use -e for a small extension set.
Vhost fuzzing: fuzz the header while sending traffic to a known IP or base host.
Host
Parameter fuzzing: fuzz parameter names or values in query strings, headers, or bodies.
Raw request mode: use -request when a precise HTTP request must be replayed.
Run a constrained first pass
Start with a small or targeted wordlist.
Bound runtime with request rate, timeout, or recursion controls when needed.
Prefer autocalibration and explicit filters instead of accepting raw output at face value.
Capture output in JSON or JSONL for later review.
Refine matcher and filter logic
Use matchers such as status, size, words, or lines when you know what success looks like.
Use filters to remove known false positives, wildcard responses, or framework noise.
Re-run with narrower conditions until the result set is small enough to inspect manually.
Escalate carefully when needed
Add recursion only when the target and scope allow it.
Limit recursion depth and stop conditions to avoid runaway jobs.
Use replay proxying only when the request stream needs manual inspection in another tool.
Interpret and report results
Separate likely findings from baseline artifacts.
Keep the exact command, wordlist assumptions, filters, and output path.
Preserve provenance and note any upstream workflow details that were kept intact.
Do verify authorization before sending any fuzzing traffic.
Do start with a baseline request and learn the application's normal error behavior.
Do use -ac or explicit filters when the target returns soft 200s or wildcard content.
Do prefer small, context-appropriate wordlists before using larger generic lists.
Do save output in JSON or JSONL when results will be reviewed, diffed, or handed off.
Do record matcher/filter choices so another operator can reproduce the scan.
Do bound recursive runs with depth or scope constraints.
Don't treat every 200 response as a finding.
Don't enable aggressive recursion on large targets without explicit approval.
Don't fuzz broad parameter or header spaces unless the user requested it and scope allows it.
Don't discard provenance if the workflow must remain traceable to the upstream source.
Troubleshooting
Symptoms: Nearly every candidate appears valid, often with the same status code and very similar body size.
Solution: The application likely returns a soft match, wildcard route, or shared error template. Capture one or more known-bad requests, then use autocalibration or explicit filters such as response size, words, or lines to remove the baseline.
Symptoms: A raw request run fails immediately or returns malformed-request behavior.
Solution: Check that request.txt is a complete HTTP request, that the FUZZ marker is in the intended location, and that -request-proto matches the actual scheme. Re-test the raw request without fuzzing if needed.
Symptoms: Recursive discovery expands too far or takes much longer than expected.
Solution: Reduce scope, set recursion limits, narrow the wordlist, or disable recursion for the first pass. Only recurse into validated hits that materially improve coverage.
Symptoms: Vhost fuzzing shows inconsistent or confusing results.
Solution: Confirm DNS and routing assumptions, compare against a known baseline host response, and filter on stable traits such as size or words rather than status code alone.
Symptoms: Output is hard to compare between runs.
Solution: Use JSON or JSONL output, keep the command line with the result file, and keep filters stable between iterations unless you are deliberately changing the test design.
Additional Resources
references/domain-notes.md — Open for compact ffuf execution notes on matcher/filter strategy, autocalibration, recursion, raw requests, scraper behavior, output formats, and configuration details.
examples/worked-example.md — Open when you need a concrete baseline-to-refinement walkthrough with commands and expected interpretation.
Related Skills
No related local skills were provided in the source context.
