Legal Recon for Web Pentesting

Reconnaissance is the first phase of a web pentest.

It is also the phase where careless testers can easily cross boundaries.

Legal recon means collecting and analyzing information only within the approved scope, using methods allowed by the rules of engagement, and avoiding activity that could harm systems, violate privacy, or create unauthorized access.

The goal is simple:

Build enough context to test intelligently without exceeding authorization.

Image: Type: Context. Mô tả: “A clean attack surface map showing approved domain, subdomains, web apps, API endpoints, and out-of-scope assets clearly separated.” caption: “Recon should map the attack surface, not expand beyond the authorized scope.”

Context

Before testing for vulnerabilities, a pentester needs to understand the target.

For web applications, that usually means identifying:

  • In-scope domains
  • In-scope subdomains
  • Application entry points
  • Login flows
  • User roles
  • APIs
  • Static resources
  • Technology stack
  • Exposed metadata
  • Public documentation
  • Error pages
  • Security headers
  • Redirect behavior
  • Third-party integrations

This does not mean scanning the whole internet. It means understanding the application surface that the client has authorized.

Scope First

Legal recon begins with scope.

Before collecting anything, clarify:

  • Which domains are in scope?
  • Which subdomains are in scope?
  • Are staging, dev, and test environments allowed?
  • Are APIs included?
  • Are mobile backends included?
  • Are third-party systems excluded?
  • Are cloud buckets or CDN assets in scope?
  • Are denial-of-service tests prohibited?
  • Are automated scanners allowed?
  • Are authenticated tests allowed?
  • Are test accounts provided?
  • What is the allowed testing window?

If the rules are unclear, stop and clarify before continuing.

A strong recon process protects both sides: the tester avoids unauthorized activity, and the client receives more precise coverage.

Passive Recon

Passive recon means collecting information without directly interacting aggressively with the target systems.

Examples:

  • Reviewing the main website
  • Reading public documentation
  • Checking public search engine results
  • Reviewing sitemap and robots.txt
  • Looking at public GitHub references
  • Reviewing public certificate transparency records
  • Checking public DNS records
  • Reading job descriptions for technology clues
  • Reviewing product documentation
  • Reviewing public API docs

Passive recon is useful because it provides context with low operational risk.

However, passive does not mean unrestricted. If the information leads to out-of-scope assets, keep them documented as out-of-scope and do not test them without approval.

Image: Type: Test case. Mô tả: “A screenshot of a recon note table with columns: Asset, Source, In Scope, Technology, Notes, Risk Hypothesis.” caption: “Recon notes should separate discovered assets from approved targets.”

Active Recon

Active recon interacts with the target systems.

Examples:

  • Visiting in-scope pages
  • Mapping application routes
  • Fingerprinting technologies
  • Checking HTTP headers
  • Reviewing login and registration flows
  • Crawling the application within rate limits
  • Identifying API endpoints from frontend traffic
  • Testing allowed user roles
  • Checking publicly exposed files

Active recon should be controlled, rate-limited, and consistent with the rules of engagement.

Do not run high-volume enumeration, intrusive scans, or destructive checks unless explicitly approved.

What to Collect

1. Asset Inventory

Create a table of assets:

Asset | Type | In Scope | Technology | Auth Required | Notes

Example:

app.example.com | Web app | Yes | React + API | Yes | Main customer portal
api.example.com | API | Yes | JSON REST | Token | Used by web and mobile clients
dev.example.com | Web app | Unknown | Unknown | Unknown | Requires scope clarification

This prevents confusion later.

2. Application Entry Points

Entry points are places where untrusted data enters the system.

Examples:

  • URL path
  • Query parameters
  • Request body
  • Headers
  • Cookies
  • File upload
  • Search box
  • Login form
  • Registration form
  • Password reset flow
  • API endpoints
  • WebSocket messages

Entry points help the tester form vulnerability hypotheses.

3. Authentication and Roles

Document authentication context:

  • Anonymous user
  • Regular user
  • Premium user
  • Organization member
  • Organization admin
  • Support user
  • System admin

Role mapping is essential for access control testing.

Many high-impact findings come from testing what one role can do to another role’s objects.

4. Technology Stack

Technology fingerprinting helps guide testing.

Look for:

  • Frontend framework
  • Backend framework
  • Server
  • CDN or WAF
  • API style
  • Authentication mechanism
  • Cloud provider clues
  • JavaScript bundles
  • Error message formats
  • Third-party scripts

Technology clues should inform testing, not replace it.

Do not assume a vulnerability exists because a technology is present. Use the stack to prioritize hypotheses.

5. Public Metadata

Review public metadata carefully:

  • robots.txt
  • sitemap.xml
  • OpenAPI or Swagger files
  • GraphQL endpoints
  • JavaScript source maps
  • Exposed .well-known paths
  • Error pages
  • Public documentation
  • Public changelogs

These files may reveal routes, endpoints, versions, or forgotten features.

Recon to Hypothesis

Recon becomes valuable when it creates testable hypotheses.

Weak recon note:

Found api.example.com

Better recon note:

Found api.example.com. Uses Bearer tokens. Multiple object IDs appear in invoice and project endpoints. Prioritize BOLA testing with two test accounts.

Another example:

Password reset flow sends reset token by email. Prioritize token expiry, token reuse, host header handling, and account enumeration checks.

The goal is not to collect endless data. The goal is to decide what to test next.

Common Mistakes

Mistake 1: Treating Discovery as Permission

Finding an asset does not mean you are allowed to test it.

If a subdomain appears during recon but is not in scope, document it and request clarification.

Mistake 2: Running Heavy Scans Too Early

Automated scanning without context can create noise, miss logic bugs, and trigger defensive systems.

Start with mapping and manual review. Use scanning only when allowed and when it answers a specific question.

Mistake 3: Ignoring Business Context

A login page for a public marketing site and a login page for an enterprise admin portal do not carry the same business risk.

Prioritize assets based on data sensitivity, user roles, exposure, and business criticality.

Mistake 4: Poor Notes

Recon without notes is wasted effort.

Good notes make testing faster and reporting easier.

[ ] Confirm written scope and rules of engagement
[ ] Separate in-scope, out-of-scope, and unclear assets
[ ] Build asset inventory
[ ] Identify application entry points
[ ] Map authentication flows and user roles
[ ] Identify API endpoints and object identifiers
[ ] Review public metadata and documentation
[ ] Fingerprint technology stack carefully
[ ] Convert observations into vulnerability hypotheses
[ ] Keep request volume reasonable and approved
[ ] Escalate unclear scope before testing

Remediation for Organizations

Organizations can make recon safer and more effective by providing:

  • Clear scope
  • Test accounts
  • Role descriptions
  • API documentation
  • Testing windows
  • Contact channel for urgent issues
  • Rate limit expectations
  • Out-of-scope list
  • Known fragile systems
  • Reporting format

A pentest is more valuable when the tester spends time testing security controls, not guessing what is allowed.

References

CTA

KevinSec can help organizations map their public web attack surface, identify exposed application entry points, and prioritize legal, business-focused web security testing. If your team is unsure what is exposed, start with a scoped recon review before deeper pentesting.