Introduction

Recon is where everything useful starts. If you want to find meaningful bugs, get better at bounty programs, or simply understand how an app stands up in the open, you need a systematic recon process. This guide lays out the whole surface you should check for any web application.
I’m not lecturing. Think of this as the checklist and mental map I’d walk you through over coffee. Short, practical, and human.

Table of contents (we will publish these as individual parts)

• Part 1: Recon foundation and lab setup
• Part 2: Passive OSINT and footprinting
• Part 3: Subdomain enumeration (passive + active merged)
• Part 4: GitHub and repo scraping for endpoints and secrets
• Part 5: Certificate transparency, CT logs and cert-based discovery
• Part 6: DNS records, zone discovery and wildcard handling
• Part 7: Subdomain permutation and brute-force techniques
• Part 8: ASN, IP harvesting and mapping ranges to assets
• Part 9: Live host discovery and safe network-level recon
• Part 10: Port/service discovery and banner analysis
• Part 11: URL collection – combined active and passive crawling
• Part 12: Visual recon and quick triage with screenshots
• Part 13: JavaScript and frontend reconnaissance (sourcemaps, endpoints)
• Part 14: Parameter extraction and hidden parameter discovery
• Part 15: Parameter pattern filtering (gf) and targeted lists
• Part 16: Automated vulnerability scanning with Nuclei (templates)
• Part 17: Sensitive file discovery and content-type filtering
• Part 18: Directory and file brute-force (ffuf, dirsearch)
• Part 19: Brute-force subdomains (ffuf + resolver pipeline)
• Part 20: API discovery and mapping (auth, CORS, endpoints)
• Part 21: Authentication flows, session analysis and multi-step auth
• Part 22: Credential and secret leakage checks (public places)
• Part 23: Cloud footprint for web apps (buckets, public storage)
• Part 24: Third-party integrations, webhooks and supply risk
• Part 25: Mobile/web interplay – APIs exposed by mobile apps
• Part 26: Monitoring, watches and continuous delta recon
• Part 27: Automation: pipelines, chaining, enrichment and dedupe
• Part 28: Scaling recon for teams and safe handoffs
• Part 29: OPSEC, legal boundaries and safe proofing
• Part 30: Reporting templates, PoC structure and remediation notes
• Part 31: End-to-end case study (lab) – runbook from start to report

Extras: curated wordlists, repo templates, and automation snippets

What this article covers right now

This page is the map. It shows every topic you need to check on a web application without leaving gaps. Each item in the table of contents will be expanded into its own post where I’ll explain why it matters, what you can do with the findings, and how to run the checks safely. Those later posts will include command examples, tuned lists, and templates you can reuse.

What you can see in each part?

Short intro to the surface – why this area matters for web apps.
What to check – concise bullets of important signals to collect.
What you can do with it – triage, attack hypotheses, or remediation insights.
How to approach it – practical steps, safe testing guidance, and quick verification methods.
Example outcomes – the kinds of findings this usually surfaces.
What to do next – where to take the output and how it feeds other recon steps.

A few highlights

Start small and build. If you rush into noisy scans or long brute forcing without cleaning up what passive OSINT gave you, you’ll miss high-value targets. A single public cert entry or git leak will often be more productive than an entire day of noisy scanning.

Keep an inventory and enrich it. Merge everything, dedupe, annotate with resolution and priority. That list becomes your triage board. Prioritize resolvable hosts with web responses and identifiable services.

Think in chains not silos. A JS endpoint discovered in frontend recon often leads straight to an API that’s more interesting than a random open port. Chaining outputs is the multiplier.

Automation is a helper, not a replacement. Automate enrichment, dedupe and template-based checks, but keep the human review for anything with business impact. False positives and edge cases hide in automation.

What the next post will be about

The next post will dive into the recon foundation and lab setup. I’ll explain how to scope a target, build a reusable findings template, and prepare a safe lab so your testing stays ethical. I’ll also include practical, copy-paste templates for note-taking and reporting.

Final note before we go

This series is designed to be practical and usable right away. I’ll keep each post short, broken into small readable parts, and packed with the exact things you need to run or teach recon. No fluff. No missing steps.

Disclaimer

This material is for educational purposes only. Use it ethically and only against targets you own or have explicit permission to test. Do not use any techniques described here in a way that violates laws, program rules, or third-party rights. If in doubt, stop and get permission.