Overview
SQLi hunting focuses on parameters that reach queries — and thoroughly identifying and testing them (safely) is key. This lesson covers parameters in SQLi hunting.
Learning objectives
- Identify parameters that are SQLi candidates.
- Explain testing parameters safely for injection.
- Connect parameter coverage to thorough hunting.
Core concept
The parameters relevant to SQLi are those whose input reaches a database query — commonly search terms, filters, sort fields, and identifiers, across all channels (query, body, path, sometimes headers/cookies). Thorough SQLi hunting requires identifying all such parameters (including hidden/undocumented ones from endpoint discovery) and testing each safely for whether its input can influence the query. Missing a parameter means a potentially-injectable input goes untested. As with the web-security module, the flaw is unsafe incorporation of the parameter into the query; testing detects this with minimal, non-destructive probes.
How it works
Leveraging parameter discovery, the researcher enumerates every parameter that could reach a query and tests each safely: submitting minimal, non-destructive inputs and observing whether the query behavior changes in ways indicating injection (per the error-patterns lesson next). Comprehensive coverage matters — SQLi can hide in a less-obvious parameter (a hidden filter, a sort field, an API body field) that casual testing misses. Testing stays in-scope and avoids destructive or data-exfiltrating actions (per program rules); the goal is to detect injectability, not to extract data. Each parameter that shows injection signals is a candidate for safe validation.
Practical example
Hunting an in-scope API, the researcher identifies several query-reaching parameters: a visible search field, a sort parameter, and a hidden filter parameter (found via endpoint discovery). Testing each safely with minimal probes, they notice the hidden filter parameter produces behavior consistent with injection, while the others appear safely parameterized. Because they tested all query-reaching parameters — not just the obvious search field — they found a candidate that casual testing would have missed. They proceed to validate it safely.
Cybersecurity relevance
Thorough parameter coverage is essential to effective SQLi hunting: SQLi can exist in any query-reaching parameter, so testing all of them (including hidden/undocumented ones) — safely — maximizes the chance of finding it, while incomplete coverage misses flaws. It builds on parameter discovery and the web-security SQLi concept. SQLi's high impact makes finding it valuable in bug bounty, and the fix is parameterization for every input. Testing must be safe and in-scope (minimal, non-destructive) per program rules. Comprehensive, safe parameter testing is the core of systematic SQLi hunting.
Common mistakes
- Testing only obvious parameters (search) and missing hidden ones (filters, sort, API body fields).
- Destructive or data-exfiltrating tests rather than minimal, safe detection.
- Not leveraging parameter discovery to enumerate all query-reaching inputs.
Key takeaways
- SQLi candidate parameters are those reaching a query (search, filters, sort, identifiers) across all channels, including hidden/undocumented ones.
- Thorough hunting tests all such parameters safely (minimal, non-destructive) — missing a parameter means an untested injectable input.
- Comprehensive, safe parameter coverage (building on parameter discovery) maximizes SQLi discovery; the fix is parameterizing every input.
Check your understanding
- Which parameters are SQLi candidates, and why must hidden ones be included?
- Why is comprehensive, safe parameter coverage important for SQLi hunting?