1. Target intake#

Before any tool runs:

• Confirm you have explicit permission to test the target (self-owned, authorized engagement, or a public VDP). No permission, no testing.
• Understand what the target actually does. A bug that’s noise in one threat model can be P1 in another.
• Map out what’s in scope and what’s off-limits. Stay inside that boundary the entire time.

2. Recon#

• Subdomain enumeration: amass, subfinder, crt.sh for cert transparency
• Tech fingerprinting: wappalyzer, whatweb, httpx for response headers
• Content discovery: feroxbuster / ffuf with curated wordlists by tech stack
• JS analysis: pull all JS, search for endpoints, secrets, internal API paths

I lean heavily on my own RECOG.py pipeline to chain these.

3. Bug classes I prioritize (web)#

In rough order of impact on most targets:

1. IDOR / broken access control: still the highest-impact class on most web apps
2. Auth bypass / session handling: race conditions, token reuse, OAuth misconfig
3. SSRF: especially via image fetchers, webhooks, URL parameter parsing
4. Server-side template injection: when frameworks expose user-rendered templates
5. Business logic: race conditions, state machine abuse, price/quantity manipulation
6. Stored XSS in admin / privileged surfaces: high impact, often overlooked

XSS in user-facing surfaces is fine but lower impact, so go for higher-leverage classes first.

4. Triage and write-up#

Before reporting:

• Reproduce on a clean account / browser (no extensions, no logged-in cookies)
• Capture minimal repro steps in 3 to 5 lines
• Describe impact in business terms, not just “I can call X endpoint”
• Provide remediation guidance. Make it easy for the team to fix it.

5. Ethics#

• Never test outside what you’re authorized to test. Period.
• No data exfiltration beyond proof of impact. One record beats a full dump.
• Disclose responsibly. Coordinate with the team, don’t publish until they’ve had time to fix and are okay with it.

This is a living document. I’ll update it as my methodology evolves.