Mastering FFUF for Hidden API Endpoint and Parameter Discovery

Mastering FFUF for Hidden API Endpoint and Parameter Discovery

Uncovering the full attack surface of an application demands more than just automated scans; it requires targeted, iterative fuzing. FFUF (Fuzz Faster U Fool) is an indispensable tool in a pentester's arsenal for precisely this purpose: systematically identifying unlinked API endpoints and hidden parameters that often expose sensitive functionality or information. This isn't about finding known CVEs; it's about pushing boundaries and revealing bespoke, often forgotten, development artifacts.

Initial Endpoint Enumeration: Casting a Wide Net

The first step in mapping an API's true surface is robust endpoint enumeration. Many modern web applications, particularly those leveraging JavaScript frameworks, obscure their backend API structure. Traditional crawlers often miss endpoints not directly referenced in client-side code or dynamically loaded. FFUF, coupled with comprehensive wordlists, excels here.

Start with common API path prefixes and well-maintained wordlists. Seclists' 'Discovery/Web-Content' and 'Discovery/Web-Content/api' directories are excellent starting points. Pay close attention to status codes beyond the typical 200 OK; a 401 Unauthorized or 302 Redirect on a path that normally returns a 404 can indicate a legitimate, protected, or moved resource.


ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt:FUZZ \
     -u https://api.target.com/api/v1/FUZZ \
     -mc 200,204,301,302,401,403 \
     -t 100 \
     -v

This command attempts to fuzz the FUZZ keyword in the URL path. The -mc flag specifies the HTTP status codes to match, broadening our discovery beyond just 'found' (200 OK) responses. The -t 100 sets the number of concurrent threads, accelerating the process. Verbose output (-v) helps in understanding the progress and identifying patterns in response lengths or contents. For initial broad discovery of potential targets and exposed services before diving into FFUF, tools like Zondex can provide a wider net, helping focus subsequent FFUF efforts on specific domains or IP ranges.

When an interesting path like /api/v1/admin or /api/v1/dev is found, it warrants deeper investigation. Recursive fuzing can be employed with the -recursion and -recursion-depth flags, allowing FFUF to automatically discover subdirectories within identified paths. This is particularly useful for complex, nested API structures.


ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt:FUZZ \
     -u https://api.target.com/api/v1/admin/FUZZ \
     -recursion \
     -recursion-depth 2 \
     -mc 200,204,301,302,401,403 \
     -e .json,.xml,.php,.asp \
     -t 100

The -e flag appends common extensions, as some endpoints might serve different content types based on their extension. This allows uncovering resources like /api/v1/admin/users.json.

Discovering Hidden Parameters: The Unseen Inputs

Once endpoints are identified, the next critical phase is parameter discovery. Many API endpoints accept a multitude of parameters, some documented, many not. These hidden parameters can unlock alternative functionality, bypass authentication checks, or lead to injection vulnerabilities.

GET Parameter Fuzing

For GET requests, parameter fuzing is straightforward. Append ?FUZZ=value or ?param=FUZZ to the URL. Use common parameter names from Seclists' 'Discovery/Web-Content/burp-parameter-names.txt' or 'Fuzzing/params' wordlists, along with common values like "1", "true", "admin", or "test".


ffuf -w /usr/share/seclists/Fuzzing/params/param-names-burp.txt:PARAM \
     -w /usr/share/seclists/Fuzzing/params/param-values-common.txt:VALUE \
     -u "https://api.target.com/api/v1/users?PARAM=VALUE" \
     -fs 0 \
     -fc 404 \
     -t 100

Here, we're fuzing both the parameter name (PARAM) and its value (VALUE). The -fs 0 flag filters out responses with a size of 0, which often correspond to empty or non-existent responses. -fc 404 filters out standard 404 Not Found responses, as we're more interested in how the application behaves when a parameter is recognized, even if its value is incorrect. Observing variations in response size, latency, or the presence of new error messages are strong indicators of parameter recognition.

POST Parameter Fuzing

Fuzing POST parameters requires specifying the HTTP method with -X POST and the request body with -d. JSON APIs are prevalent, so setting the Content-Type header is crucial.


ffuf -w /usr/share/seclists/Fuzzing/params/param-names-burp.txt:PARAM \
     -w /usr/share/seclists/Fuzzing/params/param-values-common.txt:VALUE \
     -u "https://api.target.com/api/v1/auth" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"PARAM":"VALUE"}' \
     -fs 0 \
     -fc 404 \
     -t 100

This command attempts to discover JSON body parameters for the /api/v1/auth endpoint. The single quotes around the JSON body are critical to prevent shell expansion issues. Discovering unvalidated POST parameters is a goldmine for injection vulnerabilities, logical flaws, or information disclosure.

HTTP Method Fuzing: Bypassing Restrictions

Endpoints might restrict HTTP methods, but often only on the surface. Fuzing methods can reveal hidden functionality or bypass simple access controls. An endpoint expected to only support GET or POST might respond differently to PUT, DELETE, or PATCH, potentially allowing unauthorized data modification or deletion.


ffuf -w /usr/share/seclists/Discovery/Web-Content/http-methods.txt:METHOD \
     -u https://api.target.com/api/v1/users/123 \
     -X METHOD \
     -mc 200,204,301,302,401,403 \
     -t 50

The http-methods.txt wordlist typically contains common methods like GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD. A 200 OK response to DELETE on a user ID endpoint, where a POST was expected, is a significant finding. Automated web security testing platforms like Secably complement manual FFUF efforts by covering baseline vulnerabilities, while FFUF digs deeper into custom logic and method-specific bypasses.

Advanced FFUF Techniques for Deeper Recon

Filtering Noise with Smart Rules

FFUF's strength lies in its highly customizable filtering capabilities. Instead of blindly matching status codes, filter out irrelevant responses based on size, lines, or words. This is crucial when a "not found" response consistently returns a 200 OK with a specific content length or number of lines.


# Filter by response size (fs) or lines (fl) or words (fw)
# Example: Filter out responses that are 42 lines long, often a custom 404
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt:FUZZ \
     -u https://api.target.com/api/v1/FUZZ \
     -fl 42 \
     -fs 1234,0 \
     -mc all \
     -t 100

The -fl 42 would filter out responses exactly 42 lines long. Multiple values for -fs or -fl can be comma-separated to filter out several common "not found" response patterns. The -mc all ensures all status codes are considered before filtering.

Custom Header Fuzing

Many APIs rely on custom headers for routing, authentication, or feature flags (e.g., X-API-Key, X-Version, X-Forwarded-For). Fuzing these can reveal hidden functionality or bypass security controls.


ffuf -w /usr/share/seclists/Fuzzing/http-headers.txt:HEADER \
     -u https://api.target.com/api/v1/data \
     -H "HEADER: FUZZVALUE" \
     -w /usr/share/seclists/Fuzzing/generic-fuzz.txt:FUZZVALUE \
     -mc 200,401,403 \
     -t 50

This attempts to fuzz both the header name and a common value. Observing different responses here can indicate a recognized header, even if the value is incorrect.

Proxying and Observation

For more detailed analysis of requests and responses, especially when chaining FFUF with other tools or performing manual validation, integrating with a proxy is essential. FFUF supports proxying via the -proxy flag.


ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt:FUZZ \
     -u https://api.target.com/api/FUZZ \
     -mc 200,401,403 \
     -proxy http://127.0.0.1:8080 \
     -t 50

Routing traffic through a proxy like GProxy can help manage and observe requests centrally, especially when chaining attacks or needing to inspect the raw HTTP traffic for subtle differences not immediately apparent in FFUF's summary output. This allows for closer inspection in tools like Burp Suite or OWASP ZAP.

Mastering FFUF for API reconnaissance is about intelligent brute-forcing, keen observation, and iterating on findings. It's a critical skill for any pentester looking to uncover the truly hidden attack surface of an application.