How it works
Most web vulnerabilities cluster around a small set of parameter names, because developers reuse the same habits: ?id= for objects, ?file= for includes, ?url= for fetches, ?next= for redirects, ?q= for search. Knowing which names attract which bug class turns a blank page into a focused test plan.
This cheat sheet covers the eight classes that dominate real findings — SQL injection, LFI/path traversal, SSRF, open redirect, SSTI, command injection, reflected XSS and IDOR. For each: the parameter names that usually accept input, starter probes to verify handling, the response signal that confirms the issue, and the fix that closes it. Copy any parameter list for use in your own wordlists and recon notes.
The probes are deliberately minimal: a quote, a traversal sequence, a loopback URL, {{7*7}}, ;id, a reflected SVG. Each answers one question — “does the application trust this input?” — without exfiltrating anything. Verification-first testing keeps you fast and keeps the evidence clean.
Authorized testing only. Probe systems you own or have written permission to assess. Every card includes the remediation because the goal is not just finding holes — it is shipping the fix and re-testing until the probe fails safely.
Worked example
Map one endpoint to its likely classes: a product page with ?id=14, an export with ?file=report.pdf and a login redirect with ?next=/dashboard.
| Parameter | Classes to test | First probe |
|---|---|---|
?id=14 | SQLi, IDOR | ' and ?id=15 — error, or someone else's object. |
?file=report.pdf | LFI | ../../../../etc/passwd — file content or a telling error. |
?next=/dashboard | Open redirect | ?next=https://example.com — a 3xx to an external origin. |
- Inventory parameters: List every parameter the endpoint accepts — the URL parser helps extract them.
- Match classes: Assign each parameter its likely bug classes by what it does.
- Probe and observe: Send the starter probes and read the signal column against the response.
- Fix and re-test: Apply the remediation, then replay every probe until all fail safely.
Each probe is answered by the response, not by guessing: SQL errors or boolean differences, file contents, a Location header you control. A safe application answers all three neutrally — quote treated as text, traversal rejected, redirect pinned to the allowlist.
Common errors and edge cases
- Testing classes in the wrong context. An SSTI probe in a SQL parameter wastes both of you. Match the probe to what the parameter actually does — include, fetch, redirect, render or query.
- Blind spots need blind techniques. No reflected output does not mean safe: use time delays for SQLi and command injection, and out-of-band callbacks for SSRF on your own infrastructure.
- IDOR needs two accounts. You cannot prove object-level authorization failure with one session. Compare responses between two users of the same role.
- Encoded input is still input. Base64, URL-encoding or JSON wrapping does not sanitize — decode, then assess what the server does with the value.
- Fixing the probe instead of the bug. Blocking ../../../../ or alert(1) literally leaves the next variant open. Fix the mechanism: allowlists, parameterization, output encoding, authorization checks.
Code equivalents
Turn the cheat sheet into regression tests so fixed classes stay fixed across deploys.
| Stack | Example |
|---|---|
| curl (redirect) | curl -sI 'https://yourapp.example/login?next=https://example.com' | grep -i location — must never point off-site. |
| pytest (IDOR) | Two sessions, same role: assert user B cannot GET user A's object URLs (403, not 200). |
| CI gate | Re-run each class's starter probe on staging after every deploy; a probe that succeeds blocks the release. |
Related tools
Frequently asked questions
Which parameter names are worth testing first?
id, file, url, next, q and cmd cover the majority of routine findings: object access, file inclusion, server-side fetch, redirects, search rendering and system actions. The cards list the high-value names per class.
Is probing these parameters legal?
Only on systems you own or have explicit written permission to test. The same probes on unauthorized targets are illegal in most jurisdictions, even when they cause no damage.
A probe returned nothing suspicious — is the parameter safe?
Not necessarily. Try the blind variants (time-based, out-of-band), check encoding layers, and remember absence of evidence is not evidence of absence. Verified fixes with regression tests are the real confidence.
What is the difference between IDOR and SQL injection on ?id=?
SQLi injects query syntax; IDOR simply asks for another user's object with valid syntax. IDOR is fixed with authorization checks, not parameterization — many teams patch one and forget the other.
How do I keep these classes from coming back?
Add each starter probe as an automated test against staging, gate deploys on them, and review the parameter inventory whenever new endpoints ship.
Privacy note
All processing happens in your browser. The values you enter never leave your device and are never transmitted to ToolPlex.