Part 14 – Parameter Discovery and Hidden Parameter Hunting

Introduction

You now have:

Clean URLs
API endpoints
JS-discovered paths
Live services

But the real entry points are not just endpoints.

They are parameters.

A simple ?id= or ?user= can decide:

Data access
Auth behaviour
Business logic

This is where small inputs create big impact.

Why parameter discovery matters

Most vulnerabilities live in parameters
Hidden parameters are often untested
APIs rely heavily on parameters
Business logic flaws depend on input manipulation

If endpoints are doors, parameters are keys.

What you are trying to find

Query parameters (?id=, ?user=)
POST body parameters
Hidden parameters not visible in UI
Internal parameter names from JS
Alternate parameter names

This becomes your fuzzing and testing surface.

Types of parameters you should know

1. Query parameters

/api/user?id=123

2. Body parameters

POST /login
username=admin&password=123

3. Headers

Authorization: Bearer token

4. JSON parameters

{
  "user_id": 123
}

All of these are attack points.

Tools you will use

ParamSpider – passive parameter discovery
Arjun – smart parameter discovery
ffuf – fuzzing
grep / regex – manual extraction
gf patterns – filtering
Burp Suite – manual testing

Keep automation focused.

Step-by-step parameter discovery workflow

1. Extract parameters from URLs

From your collected URLs:

cat clean_urls.txt | grep "=" > params.txt

Example output:

/api/user?id=1
/search?q=test

These are your starting points.

2. Extract parameter names only

cat params.txt | sed 's/.*?//' | tr '&' '\n' | cut -d '=' -f1 | sort -u > param_names.txt

Now you have clean parameter names like:

id
user
q
token

3. Passive parameter discovery using ParamSpider

paramspider -d example.com

Output:

Hidden parameters from archives
Historical endpoints

This often reveals:

Deprecated parameters
Internal API inputs

4. Smart parameter discovery with Arjun

arjun -u https://example.com/api/test

What it does

Sends intelligent requests
Detects hidden parameters

Very useful for APIs.

Extracting parameters from JavaScript (important)

From Part 13:

grep -oE "[a-zA-Z0-9_]+=" js/* | sort -u > js_params.txt

Also search manually:

grep -iE "id|user|token|key" js/*

JS often reveals:

Internal parameter names
Backend expectations

Building a parameter wordlist

Combine everything:

cat param_names.txt js_params.txt | sort -u > final_params.txt

Add common parameters:

id
user
uid
account
token
auth
role
admin
debug
redirect
url
next
file
path

Now you have a target-specific wordlist.

Parameter fuzzing with ffuf

Basic example:

ffuf -u "https://example.com/page?FUZZ=test" -w final_params.txt -mc all -fs 0

Explanation

Replaces FUZZ with parameter names
Detects new parameters based on response

POST parameter fuzzing

ffuf -u https://example.com/api \
-X POST \
-d "FUZZ=test" \
-w final_params.txt

This helps discover:

Hidden POST parameters
Internal inputs

Finding hidden parameters via response differences

Watch for:

Status code changes
Response size changes
New error messages

These indicate:

Valid parameter found

Example:

?page=test → 200
?admin=true → 403

Now you know:

admin is meaningful

Header parameter discovery

Test headers:

X-Forwarded-For
X-Admin
X-User

Using curl:

curl -H "X-Admin: true" https://example.com

Sometimes headers control:

Access
Roles
Debug features

Common high-impact parameters

Look for:

id → IDOR
user → access control
redirect → open redirect
file → LFI
url → SSRF
debug → info disclosure
admin → privilege escalation

These are common entry points.

Prioritisation strategy

High priority:

Auth-related parameters
ID-based parameters
File and URL parameters

Medium priority:

Search queries
Filters

Low priority:

Static inputs

Real-world use-cases

Changing user_id → IDOR
Adding admin=true → privilege escalation
Manipulating redirect → open redirect
Testing file → LFI
Using url → SSRF

These are real vulnerabilities.

Mini lab exercise (30–40 minutes)

Extract parameters:

grep "=" urls.txt > params.txt

Extract names:

sed 's/.*?//' params.txt | tr '&' '\n' | cut -d '=' -f1

Build wordlist:

cat param_names.txt > final.txt

Run ffuf:

ffuf -u "https://example.com/page?FUZZ=test" -w final.txt

Observe differences and note:

Which parameters respond
Which behave differently

Common mistakes and fixes

Mistake: Only testing visible parameters
Fix: Discover hidden ones

Mistake: Using generic wordlists only
Fix: Build target-specific list

Mistake: Ignoring response differences
Fix: Compare carefully

Mistake: Skipping JS-based parameters
Fix: Always analyse JS

Quick command summary

Extract params:

grep "=" urls.txt

Clean names:

cut -d '=' -f1

ParamSpider:

paramspider -d example.com

Arjun:

arjun -u URL

Fuzz:

ffuf -u "URL?FUZZ=test" -w wordlist

What to do after this Part

Start vulnerability testing
Try IDOR, XSS, SSRF
Test APIs deeply
Explore business logic

Now you are fully ready for real bug hunting.

Next post preview

Part 15 – Parameter Pattern Filtering (gf) and Targeted Hunting

We will cover:

Using gf patterns
Filtering high-value endpoints
Faster vulnerability detection
Smart targeting

This makes your testing efficient.

Closing thought

Most bugs are not hidden.
They are just ignored.

Parameters are where they live.

Disclaimer

This content is for educational purposes only. Use it ethically and only against targets you own or have explicit permission to test. Do not use any techniques described here in ways that break laws, platform rules, or third-party rights. If in doubt, stop and get permission.

Share the Post: