Web Application Testing

Web testing is where automation helps least and hurts most. A scanner finds the reflected XSS and misses the authorization flaw that is the actual severity, so the center of gravity is a proxy and a human reading responses. The tools below support that work; they do not replace it.

Authorized targets only

Injection and automated request tooling can corrupt data and take applications down. Confirm scope, prefer read-only proofs, and keep destructive flags off production.

The Burp workbench

Burp Suite is the workbench, and the skill is in a few of its tools, not the scanner:

• Proxy — intercept and observe. The first hour of any web test is browsing the app through Burp so the target and history fill with real requests.
• Repeater — hand-craft and replay a single request. This is where most findings are actually confirmed: change one parameter, resend, read the response. Vertical and horizontal authorization testing is a Repeater exercise — same request, another user’s identifier.
• Intruder — automate a request across a payload set: fuzzing, enumeration, credential spraying. Slower than a dedicated tool but attached to your authenticated session, which is its whole point.
• Extensions — Autorize for authorization testing at scale (it replays every request as a low-privileged user and flags what still works), and the active-scan-enhancing extensions.

The mental model: Proxy to see it, Repeater to prove it, Intruder to scale it. A tester who lives in Repeater is testing; one who lives in the scanner is triaging someone else’s output.

Injection

sqlmap -u "https://target/item?id=1" --batch --dbs: confirm and exploit SQL injection. Output: injectable parameters, the DBMS, and the databases readable through them. Next: this is confirmation and impact demonstration, not discovery — bring it a parameter you already suspect. It is loud and heavy: good for a lab or an authorized proof of impact, poor for a stealthy engagement. Start with --level 1 --risk 1 and raise only if needed; reach for --os-shell or --file-read only when RCE or file access is explicitly in scope.

sqlmap -r request.txt -p id: same, driven by a saved Burp request. Output: as above, but with your real headers, cookies and session. Next: the form to use in practice — save the request from Burp, target one parameter with -p, and sqlmap tests inside your authenticated context instead of guessing it.

For injection beyond SQL — command, template, LDAP — the workflow inverts: find the reflection by hand in Repeater, then confirm the interpreter with a targeted payload. The injection families are the map of what to try where.

Template and known-issue scanning

nuclei -u https://target -severity critical,high: template-based checks for known issues. Output: matched templates, tagged with severity. Next: fast triage for known-vulnerable components, exposed panels and misconfigurations. Verify every hit by hand: a matched template is a lead, and the false-positive rate on version-based templates is real. Keep templates updated; a stale set is the main way nuclei misses live issues.

nuclei -l live-hosts.txt -tags cve,exposure: the same across a target list from recon. Output: the same, at surface scale. Next: this is where recon output pays off — probe the whole live surface for known issues, then hand-test what matches.

Parameters and tokens

ffuf -w params.txt -u "https://target/api?FUZZ=test" -fs <baseline>: discover hidden parameters. Output: parameters the app responds to differently. Next: undocumented parameters are where mass-assignment and debug-flag findings live. arjun does the same job with built-in analysis if you prefer a purpose-built tool.

jwt_tool <token>: inspect and attack a JSON Web Token. Output: decoded header and claims, plus checks for the classic flaws. Next: the alg: none acceptance, the weak HMAC secret, the kid injection — token handling is where modern auth breaks, and the fix is server-side verification, not a cleverer token.

Where this connects

Every tool here executes some part of the web application methodology — the methodology decides what to test, these decide how. The bugs they confirm are the offensive read of insecure coding, and how much of this activity a defender sees is a question of detection quality: sqlmap is trivially detectable, a careful Repeater session much less so.