02 Web Application Reconnaissance

Mission Overview

Welcome to Lab 02 — Web Application Reconnaissance & Attack Surface Mapping.

In Lab 01, you built a safe and reusable web pentesting environment.

Now you will begin assessing the application itself.

Before testing authentication, sessions, access control, injection, APIs, or business logic, you first need to understand:

• what the application exposes

• which technologies it appears to use

• which pages and endpoints exist

• where input enters the application

• where authentication boundaries exist

• which user roles exist

• whether APIs are present

• which application areas appear security-sensitive

• which portions of the attack surface deserve deeper testing

This lab focuses on systematic mapping, not exploitation.

Mission Goal: Perform structured reconnaissance against an authorized training web application, identify its exposed attack surface, classify application functionality and inputs, map trust boundaries, and create a Web Application Attack Surface Map that will guide all later security testing.

Mission Information

Item	Details
Difficulty	Beginner
Estimated Time	90–120 minutes
Primary Skill	Web Application Reconnaissance
Secondary Skill	Attack Surface Mapping
Environment	GoHackersCloud Web Pentesting Lab
Testing Mode	Passive + Controlled Active Discovery
Primary Outcome	Web Application Attack Surface Map
Safety Level	Authorized Training Application Only

Learning Objectives

By completing this lab, you will be able to:

• confirm application scope

• build an application profile

• identify exposed web technologies

• identify visible application functionality

• enumerate pages and endpoints

• identify forms and parameters

• identify authentication interfaces

• identify user roles

• identify session-related components

• identify API endpoints

• identify file-handling functionality

• identify administrative functionality

• identify client-side resources

• identify external dependencies

• identify important HTTP methods

• identify security-sensitive workflows

• identify application trust boundaries

• classify inputs by source and sensitivity

• distinguish attack surface from vulnerability

• prioritize areas for later assessment

• document findings and evidence professionally

Core Methodology

Use:

Scope → Observe → Discover → Enumerate → Classify → Map → Prioritize

Expanded:

Authorization
     │
     ▼
Confirm Scope
     │
     ▼
Observe Application
     │
     ▼
Identify Technologies
     │
     ▼
Discover Pages / Endpoints
     │
     ▼
Identify Inputs
     │
     ▼
Identify Authentication
     │
     ▼
Identify Roles
     │
     ▼
Identify APIs / Files / Admin Areas
     │
     ▼
Map Trust Boundaries
     │
     ▼
Classify Attack Surface
     │
     ▼
Prioritize Deeper Testing

The core principle is:

You cannot assess an application effectively until you understand what the application actually exposes.

Part 1 — Confirm the Assessment Scope

Start by importing the scope from Lab 01.

Record:

ASSESSMENT ID:
GHC-WEB-LAB02-001

APPLICATION:

AUTHORIZED URL:

AUTHORIZED IP / HOSTNAME:

TEST ACCOUNTS:

TESTING WINDOW:

EXCLUDED SYSTEMS:

AUTHORIZED:
Yes

Do not expand scope simply because the application links to another system.

Part 2 — Understand Attack Surface

The application attack surface includes components an attacker or user may interact with.

Examples include:

Pages
Endpoints
Forms
Parameters
Cookies
Headers
Authentication
Sessions
APIs
File Uploads
Search
Administrative Functions
Client-Side Code
External Integrations
Redirects
Business Workflows

An attack surface is not a list of vulnerabilities.

Attack Surface ≠ Vulnerability List

Part 3 — Create the Lab Workspace

Create:

Web-Pentesting-Labs/
└── Lab-02/
    ├── 01-Scope/
    ├── 02-Application-Profile/
    ├── 03-Technology/
    ├── 04-Pages/
    ├── 05-Endpoints/
    ├── 06-Parameters/
    ├── 07-Forms/
    ├── 08-Authentication/
    ├── 09-Roles/
    ├── 10-APIs/
    ├── 11-File-Handling/
    ├── 12-Client-Side/
    ├── 13-External-Dependencies/
    ├── 14-Trust-Boundaries/
    ├── 15-Attack-Surface/
    ├── 16-Evidence/
    ├── 17-Notes/
    └── 18-Report/

Part 4 — Create the Application Profile

Record:

APPLICATION PROFILE

Application Name:

Base URL:

Protocol:

Hostname:

IP:

Authentication Required:
Yes / No / Partial

User Roles:

Primary Business Function:

Administrative Interface:
Yes / No / Unknown

API:
Yes / No / Unknown

File Upload:
Yes / No / Unknown

External Integrations:
Yes / No / Unknown

Part 5 — Browse the Application Normally

Begin as a normal user.

Do not immediately try unusual inputs.

Navigate through:

• home page

• navigation menus

• login

• registration

• account functions

• search

• help

• profile

• uploads

• dashboards

• administrative areas if authorized

Record what is visible.

This establishes the application’s expected behavior.

Part 6 — Create the Page Inventory

Example:

Page ID	Page	URL/Path	Auth Required
PG-001	Home	/	No
PG-002	Login	/login	No
PG-003	Register	/register	No
PG-004	Account	/account	Yes
PG-005	Search	/search	Partial

Do not assume undocumented pages do not exist.

This is your initial visible inventory.

Part 7 — Identify the Application Navigation Structure

Map navigation conceptually:

Home
 │
 ├── Login
 │
 ├── Register
 │
 ├── Search
 │
 └── Products
       │
       ├── Product Details
       └── Reviews

Authenticated Area
 │
 ├── Profile
 ├── Orders
 ├── Upload
 └── Logout

This helps reveal workflows and trust boundaries.

Part 8 — Record HTTP Requests During Browsing

As you browse, capture requests through the authorized HTTP inspection environment.

For each important request record:

REQUEST ID:

METHOD:

HOST:

PATH:

QUERY STRING:

HEADERS:

COOKIES:

BODY:

CONTENT TYPE:

AUTHENTICATED:
Yes / No

Part 9 — Create the Endpoint Register

The page URL alone does not represent the entire application.

Create:

Endpoint ID	Method	Path	Purpose	Auth
EP-001	GET	/	Home	No
EP-002	GET	/login	Login form	No
EP-003	POST	/login	Authentication	No
EP-004	GET	/account	Account	Yes

This becomes one of the most important artifacts in the entire web pentesting track.

Part 10 — Distinguish Page from Endpoint

For example:

/login

might expose:

GET /login

and:

POST /login

These are related but different application behaviors.

Therefore:

Page ≠ Single Endpoint Automatically

Part 11 — Identify HTTP Methods

Record methods observed:

GET
POST
PUT
PATCH
DELETE
OPTIONS
HEAD

Do not infer insecurity merely because unusual methods exist.

Record:

Endpoint	GET	POST	PUT	DELETE
/profile	Yes	Yes	Unknown	No
/api/user	Yes	Unknown	Unknown	Unknown

Part 12 — Identify Parameters

Inputs may appear in:

Query Strings

Form Fields

JSON Bodies

Cookies

Headers

Path Segments

Multipart Requests

Example:

/search?q=cloud

Parameter:

q

Part 13 — Create the Parameter Register

Parameter ID	Endpoint	Parameter	Location	Type
PAR-001	/search	q	Query	Text
PAR-002	/login	username	Body	Text
PAR-003	/login	password	Body	Secret
PAR-004	/product	id	Query	Identifier

Part 14 — Classify Parameters

Useful categories include:

Free Text

Numeric Identifier

Username

Password

Email Address

File

URL

Redirect Target

Boolean

Role

Object Identifier

Search Query

JSON Object

This classification helps determine which later security tests are appropriate.

Part 15 — Identify Hidden Inputs

Some application inputs may not be immediately visible on the rendered page.

Examples:

Hidden form fields

JavaScript-generated parameters

Cookies

Request headers

API request bodies

Record them, but do not assume they are security-sensitive until tested.

Part 16 — Identify Forms

Create:

Form ID	Page	Action	Method	Fields
FORM-001	Login	/login	POST	username/password
FORM-002	Search	/search	GET	q
FORM-003	Profile	/profile	POST	name/email

Part 17 — Classify Forms by Security Importance

Example:

High Importance

• login

• password reset

• account recovery

• money transfer

• role management

• file upload

Medium Importance

• account profile

• search

• comments

• feedback

This is prioritization—not proof of vulnerability.

Part 18 — Identify Authentication Interfaces

Look for:

Login

Registration

Logout

Password Reset

Forgot Password

MFA

Account Recovery

Remember Me

Session Expiration

Create:

AUTHENTICATION MAP

Login Endpoint:

Registration:

Password Reset:

Account Recovery:

MFA:

Logout:

Remember Me:

Authentication Cookies:

Detailed testing comes in Lab 05.

Part 19 — Identify User Roles

Example:

Anonymous

Standard User

Power User

Administrator

Record:

Role ID	Role	Accessible Areas
ROLE-001	Anonymous	Public pages
ROLE-002	User	Account/profile
ROLE-003	Admin	Administration

This prepares the student for later authorization testing.

Part 20 — Create the Role Matrix

Function	Anonymous	User	Admin
View Home	Yes	Yes	Yes
View Profile	No	Yes	Yes
Manage Users	No	No	Yes
Upload File	No	Yes	Yes

Do not test bypasses yet.

Map expected behavior first.

Part 21 — Identify Session Indicators

Observe whether authentication introduces:

• cookies

• tokens

• bearer tokens

• session identifiers

• client-side storage

Record only what is visible in the authorized traffic.

Example:

SESSION PROFILE

Session Cookie:

Secure Attribute:

HttpOnly:

SameSite:

Token Present:

Session Created After Login:
Yes / No

Detailed assessment comes later.

Part 22 — Identify API Traffic

Modern applications often communicate with backend APIs.

Look for requests such as:

/api/

/v1/

/v2/

/graphql/

or JSON-based responses.

Record:

API ID	Method	Endpoint	Auth
API-001	GET	/api/profile	Yes
API-002	POST	/api/search	Yes

Part 23 — Create the API Surface Map

Frontend
   │
   ├── /api/profile
   ├── /api/orders
   ├── /api/search
   └── /api/upload

Do not assume the API has the same access controls as the user interface.

That will be assessed later.

Part 24 — Identify JSON Inputs

Example:

{
  "name": "student",
  "email": "student@example.test"
}

Record:

• endpoint

• field name

• expected data type

• authenticated role

• whether field is user-controlled

Part 25 — Identify File-Handling Functionality

Look for:

Upload Avatar

Upload Document

Import Data

Attach File

Download Export

Generate Report

Record:

FILE FUNCTION

Endpoint:

Purpose:

Authenticated:

Accepted Type:

File Size Limit:

Stored / Processed:

Download Location:

Notes:

Do not test unsafe file behavior yet.

Part 26 — Identify Download Functionality

Downloads are also part of the attack surface.

Examples:

/download?id=123

/export/report

/files/document.pdf

Record associated object identifiers and authorization requirements.

Part 27 — Identify Redirect Functionality

Look for application functions containing values such as:

next=

return=

redirect=

url=

continue=

Record them in the parameter inventory.

Do not classify them as open redirects merely because such parameters exist.

Part 28 — Identify Search Functionality

Search interfaces frequently accept arbitrary user-controlled text.

Record:

SEARCH FUNCTION

Endpoint:

Method:

Parameter:

Authentication:

Response Type:

Reflected Input:
Observed / Not Observed / Unknown

Detailed input validation assessment comes later.

Part 29 — Identify Administrative Functionality

Look for visible authorized administrative interfaces such as:

/admin

/manage

/dashboard

/settings

Record:

• expected role

• functions available

• sensitive workflows

• related endpoints

Do not attempt bypasses in this reconnaissance lab.

Part 30 — Identify Account Management Functions

Record:

Profile Update

Email Change

Password Change

Password Reset

Account Delete

Address Management

Payment Preferences

These often become important business-logic and authorization targets later.

Part 31 — Identify Object References

Look for patterns such as:

/product?id=1001

/order/5001

/profile/42

/api/users/12

Record:

OBJECT REFERENCE

Endpoint:

Identifier:

Type:

User Controlled:
Yes / No / Unknown

Expected Ownership:

Detailed authorization testing comes in Lab 07.

Part 32 — Identify Client-Side Resources

Record:

JavaScript Files

CSS

Images

Source Maps

Client Frameworks

Static JSON

Do not treat JavaScript presence as a vulnerability.

Client-side resources can reveal application structure and API usage.

Part 33 — Review Client-Side Application Behavior

Observe whether the browser appears to:

• make API requests

• store tokens

• construct URLs

• perform redirects

• submit JSON

• generate application routes

Record useful observations.

Part 34 — Identify Technology Indicators

Application technology may be visible through:

Response Headers

Cookies

HTML

JavaScript Bundles

Error Messages

URL Structure

Application Behavior

Create:

TECHNOLOGY PROFILE

Web Server:

Backend Technology:

Frontend Framework:

Session Technology:

API Technology:

Database:
Known / Suspected / Unknown

CDN / Proxy:

Confidence:

Part 35 — Treat Fingerprinting as an Assessment

Do not write:

Server: ExampleServer
Therefore vulnerable.

Technology identification becomes a security finding only if it contributes to a validated risk.

Technology Fingerprint ≠ Vulnerability

Part 36 — Identify External Dependencies

Applications may communicate with:

• identity providers

• analytics services

• payment gateways

• CDNs

• third-party APIs

• object storage

• email systems

Create:

Dependency	Purpose	In Scope
Identity Provider	Login	No/Separate Scope
Payment Service	Payments	Excluded
API Backend	Application	Yes

This is especially important for preventing scope creep.

Part 37 — Map Scope Boundaries

Conceptually:

AUTHORIZED APPLICATION
        │
        ├── Web Frontend      ✓
        ├── Application API   ✓
        ├── Training Backend  ✓
        │
        ├── Third-Party IdP   ✕
        └── External Service  ✕

Do not test excluded dependencies.

Part 38 — Identify Trust Boundaries

A trust boundary exists where data or privilege crosses between different levels of trust.

Example:

Internet / Anonymous User
          │
          ▼
      Web Frontend
          │
          ▼
Authenticated User
          │
          ▼
      Application API
          │
          ▼
      Backend Services
          │
          ▼
         Data

These boundaries are critical during later security testing.

Part 39 — Create the Trust Boundary Register

Boundary	From	To	Key Control
TB-001	Anonymous	Authenticated Area	Authentication
TB-002	User	Admin	Authorization
TB-003	Browser	API	Authentication/Authorization
TB-004	Application	Data Store	Server-side controls

Part 40 — Identify Security-Sensitive Workflows

Examples:

Login

Password Reset

Email Change

Profile Update

File Upload

User Management

Checkout

Money Transfer

Role Change

API Key Management

Record:

Workflow	Sensitivity	Why
Password Reset	High	Account takeover risk
Role Change	High	Privilege impact
Search	Medium	User input

Part 41 — Create a Workflow Map

Example:

Login
 │
 ▼
Dashboard
 │
 ├── Profile Update
 ├── Upload File
 ├── View Orders
 └── Logout

For an admin:

Admin Login
    │
    ▼
Admin Dashboard
    │
    ├── Manage Users
    ├── Manage Roles
    └── Application Settings

Part 42 — Identify Application Data Flows

Map high-level flows such as:

User
 │
 ▼
Browser
 │
 ▼
Application
 │
 ▼
API
 │
 ▼
Database

Or:

User Upload
     │
     ▼
Web Application
     │
     ▼
File Processing
     │
     ▼
Storage

This helps identify where trust assumptions exist.

Part 43 — Classify Inputs by Trust

Create:

External/User Controlled

Form fields
Query parameters
Uploaded files
Request headers
Cookies
JSON body

Application Controlled

Server-generated identifiers
Internal configuration
Backend values

But remember that anything received from the client should generally be treated by the server as untrusted input.

Part 44 — Create the Input Trust Matrix

Input	Source	User Controlled	Security Sensitive
username	Login form	Yes	Yes
product ID	URL	Yes	Medium
role	Request body	Possibly	High
upload	File	Yes	High

Part 45 — Identify Potential Testing Categories

After reconnaissance, classify where deeper assessment is needed.

Example:

Application Area	Future Test
Login	Authentication
Session Cookie	Session Management
/order?id=	Authorization
Search Input	Input Validation
Comment Field	XSS
File Upload	File Handling
API	API Security
Checkout	Business Logic

Do not test all categories in this lab.

This is the roadmap for later labs.

Part 46 — Prioritize the Attack Surface

A simple prioritization model:

Security Sensitivity + User Control + Privilege + Business Impact + Exposure

For example:

Password Reset
High Sensitivity
+
Anonymous Access
+
Identity Impact
=
High Testing Priority

Part 47 — Create the Attack Surface Priority Matrix

Area	Exposure	Privilege Impact	Priority
Login	Public	Account	High
Password Reset	Public	Account	High
Admin Functions	Restricted	Administrative	High
Search	Public	Limited	Medium
Static CSS	Public	None	Low

Part 48 — Build the Web Attack Surface Map

Combine your observations:

                    Web Application
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
       Public           Authenticated      APIs
        Area               Area
          │                │                │
     ┌────┴────┐      ┌────┴────┐      ┌────┴────┐
     ▼         ▼      ▼         ▼      ▼         ▼
   Login     Search  Profile   Upload  User API  Data API
     │                 │         │
     ▼                 ▼         ▼
Authentication     Authorization  File Handling
     │
     ▼
 Session Management

This should become a living artifact.

Part 49 — Create the Master Attack Surface Register

Use:

ID	Component	Endpoint	Input	Auth	Role	Priority
AS-001	Login	/login	username/password	No	Anonymous	High
AS-002	Search	/search	q	No	Anonymous	Medium
AS-003	Profile	/profile	user data	Yes	User	High
AS-004	Upload	/upload	file	Yes	User	High
AS-005	Admin	/admin	multiple	Yes	Admin	High

Part 50 — Document Unknowns

Your map should include unknowns.

Examples:

API authentication:
Unknown

Password reset token lifetime:
Unknown

Admin backend endpoints:
Unknown

Upload storage location:
Unknown

Unknown does not mean insecure.

It means:

Requires further investigation.

Part 51 — Identify Reconnaissance Gaps

Examples:

Some functionality inaccessible to current role.

API documentation unavailable.

Application requires second test user.

One workflow depends on excluded third-party service.

Client-side routing obscures backend calls.

Create:

Gap	Impact	Next Lab
No second user	Cannot compare authorization	Lab 07
API behavior unclear	Incomplete API map	Lab 12

Part 52 — Preserve Reconnaissance Evidence

Capture evidence for:

• application landing page

• navigation structure

• important HTTP requests

• important HTTP responses

• authentication page

• key forms

• API traffic

• user roles

• file functionality

• attack surface map

Do not screenshot every page just to increase evidence volume.

Capture evidence that supports your map.

Part 53 — Create the Evidence Register

Evidence ID	Type	Description
EV-001	Browser	Application landing page
EV-002	HTTP	Initial application request
EV-003	HTTP	Login request structure
EV-004	Browser	Authenticated dashboard
EV-005	HTTP	API request
EV-006	Browser	File upload function

Part 54 — Create the Reconnaissance Findings Register

This lab may produce mostly observations rather than vulnerabilities.

Use:

OBSERVATION ID:

COMPONENT:

DESCRIPTION:

SECURITY RELEVANCE:

EVIDENCE:

FOLLOW-UP TEST:

PRIORITY:

Example:

OBSERVATION:
Application exposes separate user and administrative roles.

SECURITY RELEVANCE:
Authorization boundaries exist between standard and
administrative functionality.

FOLLOW-UP:
Test in Lab 07 — Authorization & Access Control Assessment.

Part 55 — Do Not Inflate Findings

Bad:

Finding:
Login page exists.

Severity:
High.

That is not a vulnerability.

Better:

Observation:
Public authentication endpoint identified.

Follow-Up:
Authentication security assessment required.

Part 56 — Build the Assessment Dashboard

Area	Mapped	Priority	Future Lab
Technology	Yes	Medium	02/03
HTTP	Yes	High	03
Endpoints	Yes	High	04
Authentication	Yes	High	05
Session	Partial	High	06
Authorization	Partial	High	07
Inputs	Yes	High	08
Client-Side	Partial	High	09
File Handling	Yes	High	10
Server-Side	Partial	High	11
API	Yes	High	12
Business Logic	Partial	High	13

Part 57 — Reconnaissance Completion Criteria

You should be able to answer:

Application

What is the application’s purpose?

Pages

What major pages exist?

Endpoints

Which important HTTP endpoints exist?

Inputs

Where does user-controlled data enter?

Authentication

Where are authentication boundaries?

Roles

What user roles exist?

Sessions

How does the application appear to maintain authentication state?

API

Are backend APIs present?

Files

Can users upload or download files?

Admin

Is administrative functionality present?

External Dependencies

Which linked systems are out of scope?

Trust Boundaries

Where does data or privilege cross between trust levels?

Mission Challenge

Complete:

WEB APPLICATION RECONNAISSANCE

Assessment ID:

Analyst:

Date:


SCOPE

Application:

Base URL:

Authorized:
Yes / No

Excluded Systems:


APPLICATION PROFILE

Primary Function:

Protocol:

Authentication:

Roles:

API:

File Handling:

Administrative Functions:


TECHNOLOGY

Web Server:

Backend:

Frontend:

Session Technology:

API Technology:

Confidence:


PAGE INVENTORY

Public Pages:

Authenticated Pages:

Admin Pages:

Other:


ENDPOINTS

GET Endpoints:

POST Endpoints:

API Endpoints:

Other Methods:


PARAMETERS

Query Parameters:

Body Parameters:

JSON Fields:

Cookies:

Headers:

Object Identifiers:

URL Parameters:


FORMS

Login:

Registration:

Search:

Profile:

Password Reset:

File Upload:

Other:


AUTHENTICATION

Login:

Logout:

Registration:

Password Reset:

MFA:

Recovery:


ROLES

Anonymous:

Standard User:

Administrative User:

Other:


SESSION

Cookies:

Tokens:

Client Storage:

Session Boundary:


API

API Present:
Yes / No

Endpoints:

Authentication:

Data Format:


FILE HANDLING

Upload:

Download:

Import:

Export:

Accepted Types:


CLIENT SIDE

JavaScript:

API Calls:

Client Routes:

Client Storage:


EXTERNAL DEPENDENCIES

Dependency 01:

In Scope:
Yes / No

Dependency 02:

In Scope:
Yes / No


TRUST BOUNDARIES

Boundary 01:

Boundary 02:

Boundary 03:


HIGH-RISK WORKFLOWS

Workflow 01:

Reason:

Workflow 02:

Reason:

Workflow 03:

Reason:


ATTACK SURFACE PRIORITIES

Priority 01:

Priority 02:

Priority 03:

Priority 04:

Priority 05:


RECONNAISSANCE GAPS

Gap 01:

Impact:

Gap 02:

Impact:


FINAL ASSESSMENT

Application Mapped:
Yes / No

Endpoint Inventory Complete:
Yes / No

Input Inventory Complete:
Yes / No

Roles Identified:
Yes / No

Trust Boundaries Identified:
Yes / No

High-Priority Areas Identified:
Yes / No

Ready for HTTP Analysis:
Yes / No

What Not to Do

Do not:

Test systems outside the approved scope

Follow third-party links into unauthorized testing

Perform destructive discovery

Treat every hidden endpoint as a vulnerability

Treat every parameter as injectable

Assume a technology version is vulnerable

Assume administrative URL exposure means authorization bypass

Assume unusual HTTP methods are insecure

Assume API presence means API vulnerability

Treat a public endpoint as a security issue merely because it is public

Confuse user-controlled input with confirmed injection

Confuse object identifiers with access-control vulnerabilities

Inflate observations into findings

The professional rule is:

Reconnaissance identifies where security testing should occur. It does not determine the result of that testing.

Professional Distinctions

Always distinguish:

Attack Surface
      ≠
Vulnerability

Endpoint Discovered
      ≠
Endpoint Exploitable

Parameter Present
      ≠
Injection Vulnerability

Object Identifier
      ≠
Authorization Bypass

Admin Endpoint
      ≠
Unauthorized Admin Access

API Endpoint
      ≠
Insecure API

Technology Identified
      ≠
Known Vulnerability Applicable

Session Cookie
      ≠
Session Weakness

File Upload
      ≠
Unsafe File Upload

Client-Side JavaScript
      ≠
Client-Side Vulnerability

External Dependency
      ≠
Authorized Target

Interesting Behavior
      ≠
Validated Finding

Evidence Requirements

Capture:

• scope record

• application profile

• application landing page

• page inventory

• navigation map

• HTTP request samples

• HTTP response samples

• endpoint register

• HTTP method inventory

• parameter register

• form inventory

• authentication map

• user-role map

• role matrix

• session profile

• API surface map

• file-handling profile

• account-management functions

• object-reference inventory

• client-side resource inventory

• technology profile

• external dependency map

• trust-boundary register

• sensitive-workflow inventory

• input trust matrix

• attack-surface priority matrix

• Master Attack Surface Register

• reconnaissance gaps

• evidence register

• assessment dashboard

Mission Deliverables

Complete:

• authorization reconfirmed

• application profile completed

• visible application mapped

• pages inventoried

• endpoints inventoried

• methods documented

• parameters identified

• forms identified

• authentication interfaces mapped

• user roles identified

• role matrix built

• session indicators documented

• API traffic identified

• API surface mapped

• file functionality mapped

• download functionality mapped

• object references documented

• administrative functions mapped

• client-side resources reviewed

• technology indicators documented

• external dependencies identified

• scope boundaries preserved

• trust boundaries mapped

• sensitive workflows identified

• application data flows mapped

• user-controlled inputs classified

• deeper testing areas identified

• attack surface prioritized

• unknowns documented

• reconnaissance gaps documented

• evidence collected

• Master Attack Surface Map completed

Lab Report Template

# Lab 02 — Web Application Reconnaissance & Attack Surface Mapping

## Executive Summary

## Mission Objective

## Authorization & Scope

## Application Profile

## Application Architecture

## Technology Profile

## Page Inventory

## Navigation Structure

## Endpoint Inventory

## HTTP Methods

## Parameter Inventory

## Forms

## Authentication Surface

## User Roles

## Role Matrix

## Session Indicators

## API Surface

## File Handling

## Account Management

## Object References

## Administrative Functions

## Client-Side Resources

## External Dependencies

## Scope Boundaries

## Trust Boundaries

## Application Data Flows

## Security-Sensitive Workflows

## Input Trust Matrix

## Attack Surface Priority Matrix

## Master Attack Surface Map

## Reconnaissance Gaps

## Observations

## Evidence Register

## Areas Requiring Further Testing

## Limitations

## Conclusion

Knowledge Check

Question 1 — What is the purpose of application reconnaissance?

To understand the application’s exposed components, inputs, workflows, trust boundaries, and testing priorities before deeper security assessment.

Question 2 — Is a discovered endpoint automatically vulnerable?

No.

Discovery establishes attack surface, not vulnerability.

Question 3 — Why identify parameters?

Because they show where application-controlled or user-controlled data enters application processing.

Question 4 — Does an object identifier prove an authorization vulnerability?

No.

It identifies an area where authorization controls may need assessment.

Question 5 — Why map user roles?

Because access expectations between different privilege levels are essential for later authorization testing.

Question 6 — Why identify APIs during reconnaissance?

Modern applications often perform significant backend activity through APIs that may not be obvious from visible pages.

Question 7 — Why map external dependencies?

To understand architectural relationships and, critically, prevent testing from crossing the authorized scope.

Question 8 — What is a trust boundary?

A point where data, identity, or privilege moves between components or security contexts with different levels of trust.

Question 9 — Should every observation become a finding?

No.

Only validated security weaknesses with defensible relevance should become findings.

Question 10 — What is the central question?

“What does this web application expose, where does it accept input, which trust boundaries exist, and which parts deserve deeper security testing?”

Skills Achieved

After completing this lab, you should understand:

• web application reconnaissance

• application profiling

• web technology identification

• page enumeration

• endpoint mapping

• HTTP method inventory

• parameter mapping

• form mapping

• authentication surface mapping

• role identification

• session indicator identification

• API discovery

• file-function discovery

• object-reference identification

• administrative surface mapping

• client-side reconnaissance

• dependency mapping

• scope-boundary management

• trust-boundary mapping

• sensitive-workflow identification

• input classification

• attack-surface prioritization

• reconnaissance evidence management

Professional Takeaway

A weak reconnaissance process looks like:

Open Website
     ↓
Run Tool
     ↓
Collect URLs
     ↓
Start Testing Randomly

A professional process looks like:

Confirm Scope
     ↓
Understand Application
     ↓
Observe Normal Behavior
     ↓
Identify Technologies
     ↓
Map Pages
     ↓
Map Endpoints
     ↓
Map Parameters
     ↓
Map Forms
     ↓
Map Authentication
     ↓
Map Roles
     ↓
Map APIs
     ↓
Map File Functions
     ↓
Map Dependencies
     ↓
Identify Trust Boundaries
     ↓
Identify Sensitive Workflows
     ↓
Classify Inputs
     ↓
Prioritize Attack Surface
     ↓
Plan Deeper Testing

What’s Next?

➡️ Lab 03 — HTTP, HTTPS & Web Request Analysis

In the next lab, you will move from mapping what the application exposes to understanding exactly how the browser and application communicate.

You will work with:

• HTTP requests

• HTTP responses

• methods

• paths

• parameters

• headers

• cookies

• content types

• redirects

• status codes

• authenticated vs unauthenticated requests

• request bodies

• JSON

• multipart forms

• security headers

• request/response comparison

• evidence preservation

The methodology becomes:

Capture → Parse → Compare → Modify Safely → Observe → Correlate → Document

And the central question will be:

“Can you understand a web request well enough to identify which parts control application behavior, identity, state, input, and authorization before attempting deeper security validation?”