Overview
This is the shared execution harness for the FIND/EXPLOIT specialists. They decide what to
test — access-control-testing, authentication-testing, business-logic-testing,
api-security-testing (and Tier-2 classes like injection / client-side / file-upload). This skill
is how you run their tests safely against a live app: set up the lab/proxy/scanners, drive the
tools, and capture proof in a consistent format.
Core principle: A finding isn't real until you've reproduced it. A PoC ends the debate. The specialists own the attack recipes; this skill owns safe execution and evidence.
⚠️ Authorization Gate — STOP if not all true
Do not proceed unless all hold:
- You own the target, or have written authorization to test it.
- Target is a lab / staging / local instance — not third-party production.
- You will not run destructive or DoS techniques, and won't touch real user data.
If any box is unchecked → stop and stay in security-code-audit on code you control.
Scope discipline (non-destructive by default)
- Allowed: read-only recon, fingerprinting, single-request PoCs, reading your own test data, proving an IDOR with two test accounts you created.
- Avoid: load/stress/DoS, mass scanning, automated exploitation that writes/deletes real data, techniques whose only purpose is evasion of monitoring. Throttle scanners; use test accounts.
Workflow (recon → map → validate → prove)
- Recon / fingerprint — what's exposed, what stack, what version.
- Map — enumerate endpoints, params, auth flows (mirror the threat model).
- Validate — take the attack recipe from the relevant specialist skill and run it with the smallest request that proves the bug. (This skill = the tooling; the specialist = the payload.)
- Prove — capture the exact request/response as the PoC; note impact.
See references/tool-playbook.md for how to drive each tool. For what to send, go to the
specialist (e.g. IDOR recipes → access-control-testing, ATO flows → authentication-testing).
Quick reference — tool per goal
| Goal | Tool |
|---|---|
| Port/service/version | nmap -sV |
| TLS config | testssl.sh, sslscan |
| Web server quick issues | nikto |
| Content/endpoint discovery | ffuf, gobuster, feroxbuster |
| Manual request crafting | curl, httpie, Burp Repeater |
| Intercept / spider / scan | OWASP ZAP, Burp Suite |
| SQLi confirmation | sqlmap (on your own app, --batch, scoped) |
| Mobile traffic | Burp/ZAP proxy + device, Frida (pinning), objection |
| Secrets in code/binary | trufflehog, gitleaks, apktool+jadx |
Output: validated findings
For each confirmed item:
- Finding ID (link back to the audit register)
- Reproduction: exact command / request
- Evidence: response excerpt proving impact (redact real data)
- Confirmed severity & impact
- → hand to
security-hardeningfor the fix and re-test.
Common mistakes
- Testing prod or third-party assets "just to check" — that's the line you don't cross.
- Running
sqlmap/scanners full-throttle and knocking over your own staging. - Calling something exploitable from theory alone — reproduce it.
- Keeping noisy PoCs — minimal request, minimal blast radius.