Parameter fuzzing is the process of discovering hidden, undocumented, or vulnerable parameters in web applications by sending a large number of test requests. It is an essential technique in web application security testing, bug bounty hunting, and penetration testing. Attackers and security researchers use it to find:
Hidden API parameters that can modify the behavior of a request.
Potentially vulnerable inputs for SQL Injection, Cross-Site Scripting (XSS), Server-Side Request Forgery (SSRF), etc.
Authentication and authorization bypass issues through parameter tampering.
Many web applications use parameters in URLs, query strings, POST requests, and headers to pass data between the client and the server. Some parameters are intentionally exposed, while others may be hidden or undocumented.
How Does Parameter Fuzzing Work?
Identify the endpoint: Choose a target URL where parameters might exist (e.g.,
https://example.com/profile?user=123).Use a wordlist of common parameter names: Attackers use predefined lists of parameter names (like
id, user, token, admin) to check if the server responds differently.Observe the responses: If the server behaves differently when a new parameter is introduced, it might indicate a hidden parameter.
Test for vulnerabilities: Once parameters are found, they are tested for security weaknesses like SQL Injection, XSS, and IDOR (Insecure Direct Object References).
Common Use Cases of Parameter Fuzzing
Discovering Hidden GET Parameters
Web applications often have hidden parameters that control user authentication, page access, or API behavior. By fuzzing URLs with different parameter names, security testers can find parameters not intended to be publicly known.
Example:
If a web page loads user data with:
https://example.com/profile?id=123
A tester can fuzz for hidden parameters like user, uid, or token:
https://example.com/profile?user=123
https://example.com/profile?uid=123
https://example.com/profile?token=abc123
If the server accepts one of these and displays different content, it means a hidden parameter exists.
Fuzzing for Vulnerable Parameters (SQLi, XSS, LFI, etc.)
Once parameters are found, they can be tested for security weaknesses. Attackers can inject malicious input into parameters to exploit vulnerabilities.
SQL Injection (SQLi):
If a parameter like
id=123exists, fuzzing might reveal an SQL injection point by sending:id=' OR 1=1-- id=123; DROP TABLE users;
Cross-Site Scripting (XSS):
If a parameter reflects user input on a webpage, it can be tested for XSS:
search=<script>alert(1)</script> comment=<img src=x onerror=alert(1)>
Local File Inclusion (LFI):
If a parameter loads files, it can be tested for LFI:
file=../../etc/passwd file=/var/www/html/index.php
Testing API Endpoints for Sensitive Parameters
APIs often have undocumented parameters that can expose sensitive data or alter application behavior. Fuzzing can help find these:
Example:
A login API might accept additional undocumented parameters like debug=true:
https://api.example.com/login?username=admin&password=1234&debug=true
If this exposes sensitive information in the response, it could be a security risk.
Bypassing Authentication and Authorization
Some web applications use parameter-based authentication (e.g., admin=true). Fuzzing can reveal security flaws where a simple parameter change can escalate privileges.
Example:
An admin panel might be protected by a hidden parameter:
https://example.com/dashboard?admin=false
Fuzzing can reveal:
https://example.com/dashboard?admin=true
If this grants access to restricted content, it’s a critical security issue.
Finding Business Logic Flaws (IDOR)
Parameter fuzzing can help identify Insecure Direct Object References (IDOR), where a user can access another user's data by modifying a parameter value.
Example:
A user profile page with:
https://example.com/profile?user=123
If changing user=123 to user=124 loads another user’s profile, it’s an IDOR vulnerability.
GET Request Fuzzing
GET method fuzzing involves testing query parameters in URLs to discover hidden parameters, security vulnerabilities, or undocumented API functionalities. Since GET requests send data as part of the URL, they are easily accessible and often used for navigation, API calls, and retrieving data.
GET parameters are typically passed in the URL after a ? symbol, like:
https://example.com/profile?id=123
Fuzzing these parameters helps discover hidden or undocumented parameters that may reveal sensitive functionality or lead to security vulnerabilities like: Choosing the Right Wordlist To enumerate GET parameters, SecLists provides a useful wordlist: /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt This wordlist contains common parameter names used by web applications.
Running FFUF to Enumerate GET Parameters To discover hidden parameters, replace an existing parameter in the URL with FUZZ:
ffuf -w /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt -u "http://example.com/profile?FUZZ=key" -mc 200
Explanation of Flags:
-u → Specifies the target URL, where FUZZ will be replaced by words from the wordlist.
-w → Defines the wordlist to use for fuzzing.
-mc 200 → Matches responses with HTTP status 200 (to filter valid parameters).
POST Request Fuzzing
The main difference between POST requests and GET requests is that POST requests are not passed with the URL and cannot simply be appended after a ? symbol. POST requests are passed in the data field within the HTTP request. Check out the Web Requests module to learn more about HTTP requests.
To fuzz the data field with ffuf, we can use the -d flag, as we saw previously in the output of ffuf -h. We also have to add -X POST to send POST requests. Tip: In PHP, "POST" data "content-type" can only accept "application/x-www-form-urlencoded". So, we can set that in "ffuf" with "-H 'Content-Type: application/x-www-form-urlencoded'".
So, let us repeat what we did earlier, but place our FUZZ keyword after the -d flag:
ffuf -w /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt:FUZZ -u http://example.com/profile -X POST -d 'FUZZ=key' -H 'Content-Type: application/x-www-form-urlencoded'
As we can see this time, we got a couple of hits, the same one we got when fuzzing GET and another parameter, which is id. Let's see what we get if we send a POST request with the id parameter. We can do that with curl, as follows:
curl http://example.com/profile -X POST -d 'id=key' -H 'Content-Type: application/x-www-form-urlencoded'
Value Fuzzing
After finding a working parameter, we need to find the right value that will give us the flag content we want. This part will cover how to fuzz for parameter values, which is quite similar to fuzzing for parameters once we have our wordlist ready.
Custom Wordlist
When fuzzing parameter values, we might not always have a ready-made wordlist that fits our needs because each parameter expects a specific type of value. For some parameters, like usernames, we can find a wordlist of possible usernames or create our own based on likely website users. In these cases, we can look in the seclists directory for a wordlist that matches the parameter we're targeting. For custom parameters, we may need to make our own wordlist.
For example, we can assume the id parameter uses numbers. These IDs could be in a custom format or sequential, like from 1-1000 or 1-1000000, and so on. We'll start with a wordlist containing numbers from 1-1000. There are several ways to make this wordlist, such as typing the IDs into a file manually or using a script with Bash or Python. The easiest way is to use the following Bash command to write all numbers from 1-1000 to a file:
for i in $(seq 1 1000); do echo $i >> ids.txt; done
Value Fuzzing
Our command should be fairly similar to the POST command we used to fuzz for parameters, but our FUZZ keyword should be put where the parameter value would be, and we will use the ids.txt wordlist we just created, as follows:
ffuf -w ids.txt:FUZZ -u http://example.com/profile -X POST -d 'id=FUZZ' -H 'Content-Type: application/x-www-form-urlencoded'