Lab 04 - Web Content, Endpoint & Parameter Discovery

Mission Overview

Welcome to Lab 04 — Web Content, Endpoint & Parameter Discovery.

In Lab 03, you learned how to understand HTTP requests and responses in detail.

Now you will expand the application map.

Modern web applications often expose functionality through more than just visible navigation menus. Important application behavior may exist in:

• routes

• hidden or less-obvious pages

• API paths

• background requests

• legacy paths

• client-side routes

• form actions

• object identifiers

• parameters

• downloadable resources

• administrative interfaces

This lab focuses on discovering and organizing that surface in a controlled and authorized way.

Mission Goal: Systematically discover, verify, classify, deduplicate, and prioritize web application content, endpoints, and parameters so later security testing is based on a complete and evidence-backed attack surface map.

Mission Information

Item	Details
Difficulty	Beginner–Intermediate
Estimated Time	90–120 minutes
Primary Skill	Endpoint & Parameter Discovery
Secondary Skill	Attack Surface Expansion
Environment	GoHackersCloud Web Pentesting Lab
Testing Mode	Controlled Discovery
Primary Outcome	Master Endpoint & Parameter Register
Safety Level	Authorized Training Application Only

Learning Objectives

By completing this lab, you will be able to:

• identify visible application content

• identify less-obvious endpoints

• distinguish pages from backend endpoints

• identify client-side application routes

• identify API paths

• discover parameters in query strings

• discover form and body parameters

• identify object identifiers

• identify file and download endpoints

• identify administrative interfaces

• classify authenticated vs unauthenticated endpoints

• distinguish discovered from verified endpoints

• identify duplicate routes

• detect legacy or archived functionality

• prioritize endpoints for later testing

• maintain evidence for endpoint discovery

• build a reusable attack-surface register

Core Methodology

Use:

Seed → Discover → Verify → Classify → Deduplicate → Map → Prioritize

Expanded:

Known Application
      │
      ▼
Seed Endpoints
      │
      ▼
Discover Additional Content
      │
      ├── Navigation
      ├── HTTP Traffic
      ├── Forms
      ├── Client-Side Resources
      ├── API Calls
      └── Authorized Discovery
      │
      ▼
Verify Endpoint
      │
      ▼
Classify
      │
      ├── Public
      ├── Authenticated
      ├── Administrative
      ├── API
      ├── File
      └── Legacy
      │
      ▼
Identify Parameters
      │
      ▼
Deduplicate
      │
      ▼
Prioritize

The core principle is:

A discovered path is not useful until you know what it does, who can access it, and why it matters.

Part 1 — Confirm Scope

Record:

ASSESSMENT ID:
GHC-WEB-LAB04-001

APPLICATION:

BASE URL:

AUTHORIZED HOSTS:

AUTHORIZED PATHS:

TEST ACCOUNTS:

EXCLUDED SYSTEMS:

AUTHORIZED:
Yes

Do not treat linked third-party systems as automatically in scope.

Part 2 — Create the Lab Workspace

Create:

Web-Pentesting-Labs/
└── Lab-04/
    ├── 01-Scope/
    ├── 02-Seeds/
    ├── 03-Visible-Content/
    ├── 04-Discovered-Content/
    ├── 05-Endpoints/
    ├── 06-Parameters/
    ├── 07-Forms/
    ├── 08-APIs/
    ├── 09-Client-Side/
    ├── 10-Files/
    ├── 11-Admin/
    ├── 12-Legacy/
    ├── 13-Classification/
    ├── 14-Prioritization/
    ├── 15-Evidence/
    ├── 16-Notes/
    └── 17-Report/

Part 3 — Import Your Seed Endpoints

Use your existing endpoint map from Labs 02 and 03.

Example:

/
 /login
 /register
 /search
 /profile
 /upload
 /api/profile

Create:

Seed ID	Path	Source
SEED-001	/	Navigation
SEED-002	/login	Browser
SEED-003	/api/profile	HTTP traffic

These become the starting points for deeper discovery.

Part 4 — Review Visible Navigation

Inspect normal application navigation.

Document:

• menu links

• footer links

• account links

• dashboard links

• help links

• administrative links where authorized

• upload/download functions

Create:

Page	Path	Role
Home	/	Public
Account	/account	User
Admin	/admin	Admin

Part 5 — Identify Form Actions

Forms often reveal endpoints that are not obvious from navigation.

Example:

<form action="/profile/update" method="POST">

Record:

FORM ID:
FORM-004

PAGE:
/profile

ACTION:
/profile/update

METHOD:
POST

AUTH:
Yes

Part 6 — Create the Form Action Register

Form	Action	Method	Auth
Login	/login	POST	No
Profile Update	/profile/update	POST	Yes
Search	/search	GET	No

Part 7 — Identify Endpoints from HTTP Traffic

While browsing normally, review captured requests.

You may observe application endpoints such as:

/api/profile

/api/orders

/api/search

/session/check

/preferences/update

These may never appear as clickable links.

Record each one.

Part 8 — Create the HTTP-Discovered Endpoint Register

Endpoint ID	Method	Path	Source
EP-010	GET	/api/profile	Browser traffic
EP-011	POST	/preferences/update	Browser traffic

Part 9 — Review Client-Side Resources

Client-side resources can reveal application structure.

Review authorized JavaScript or application resources for:

• route names

• API endpoints

• path constants

• resource URLs

• feature names

Record only relevant application structure.

Do not treat the presence of a hidden route string as proof of a security issue.

Part 10 — Create the Client-Side Route Register

Route ID	Route	Source	Verified
CSR-001	/dashboard	JavaScript	Yes
CSR-002	/api/orders	JavaScript	Yes
CSR-003	/admin/report	JavaScript	Pending

Part 11 — Distinguish Discovered from Verified

Use:

Discovered
Verified
Unavailable
Out of Scope
Unknown

Example:

/admin/report

Status:
Discovered

Verification:
Pending

Do not write:

Admin page exists and is accessible

until you have actually verified it appropriately.

Part 12 — Verify Endpoints Safely

For a discovered endpoint, record:

ENDPOINT:

METHOD:

EXPECTED ROLE:

REQUEST SENT:
Yes / No

STATUS:

REDIRECT:

CONTENT TYPE:

AUTH REQUIRED:

VERIFIED:
Yes / No

Verification means understanding basic behavior.

It does not mean attempting exploitation.

Part 13 — Classify Endpoint Access

Use:

Public

Authenticated

Role Restricted

Administrative

API

Internal/Backend

Unknown

Create:

Endpoint	Classification
/login	Public
/profile	Authenticated
/admin	Administrative

Part 14 — Identify API Endpoints

Look for patterns such as:

/api/

/api/v1/

/api/v2/

/graphql

Record:

API ID:

METHOD:

PATH:

AUTH:

CONTENT TYPE:

PURPOSE:

OBJECT IDENTIFIER:

PARAMETERS:

Part 15 — Build the API Endpoint Register

API ID	Method	Endpoint	Auth	Purpose
API-001	GET	/api/profile	Yes	User profile
API-002	GET	/api/orders	Yes	Orders
API-003	POST	/api/search	Yes	Search

Part 16 — Identify Query Parameters

Example:

/search?q=cloud&page=2

Record:

q
page

Create:

Param ID	Endpoint	Parameter	Location
PAR-001	/search	q	Query
PAR-002	/search	page	Query

Part 17 — Identify Body Parameters

Example:

POST /profile/update

body:

name=student
email=student@example.test

Record:

name
email

Part 18 — Identify JSON Parameters

Example:

{
  "user_id": 42,
  "email": "student@example.test"
}

Record:

Parameter	Type	Security Relevance
user_id	Identifier	Authorization-related
email	Text	User-controlled

Part 19 — Identify Path Parameters

Example:

/orders/5001

Possible path parameter:

5001

Record:

ENDPOINT PATTERN:
/orders/{id}

PARAMETER:
id

LOCATION:
Path

Part 20 — Identify Cookie Parameters

Application state may appear in cookies.

Example:

Cookie: theme=dark; session=<value>

Record both, but classify appropriately.

Not every cookie is security-sensitive.

Part 21 — Identify Header Inputs

Some application behavior may depend on headers.

Examples:

Authorization
Content-Type
Origin
Referer
X-Requested-With

Record them where relevant.

Part 22 — Build the Master Parameter Register

Param ID	Endpoint	Name	Location	User Controlled	Priority
PAR-001	/search	q	Query	Yes	Medium
PAR-002	/profile/update	email	Body	Yes	High
PAR-003	/orders/{id}	id	Path	Yes	High
PAR-004	/api/user	role	JSON	Unknown	High

Part 23 — Classify Parameter Types

Use:

Free Text

Numeric

Object Identifier

Username

Password

Email

URL

Redirect

Role

Token

Filename

File

Boolean

Search

JSON Object

Part 24 — Identify Object References

Look for:

id=123

user=42

order=5001

account=7002

Record them as authorization-relevant.

Do not classify them as IDOR yet.

Part 25 — Build the Object Reference Register

Object	Endpoint	Parameter	Expected Owner
Order	/orders/{id}	id	User
Profile	/api/user/{id}	id	User
Report	/report?id=	id	Role-dependent

Part 26 — Identify Download Endpoints

Look for:

/download

/export

/report

/files/

Create:

DOWNLOAD ID:

PATH:

PARAMETER:

FILE TYPE:

AUTH:

OBJECT IDENTIFIER:

EXPECTED OWNER:

Part 27 — Identify Upload Endpoints

Record:

/upload

/api/files

/avatar/upload

Create:

Endpoint	Field	Auth	Purpose
/upload	file	Yes	Document upload
/avatar/upload	avatar	Yes	Profile image

Part 28 — Identify Administrative Endpoints

Examples:

/admin

/manage

/admin/users

/admin/reports

Record:

• expected role

• visible or discovered source

• verification status

Do not attempt bypass testing in this lab.

Part 29 — Create the Admin Endpoint Register

Endpoint	Expected Role	Verified
/admin	Admin	Yes
/admin/users	Admin	Yes
/admin/report	Admin	Pending

Part 30 — Identify Legacy or Archived Paths

Applications sometimes retain older functionality.

Examples:

/old/

/legacy/

/v1/

/backup/

If discovered legitimately within the training environment, record them.

Do not assume legacy means vulnerable.

Part 31 — Create the Legacy Content Register

Path	Type	Status	Relevance
/v1/	Older API	Active	High
/old-dashboard	Legacy UI	Disabled	Medium

Part 32 — Identify Error and Fallback Routes

Record behavior for naturally observed:

404

redirects

default routes

custom error pages

This can help distinguish:

Real endpoint
vs
Generic application fallback

Part 33 — Avoid False Endpoint Discovery

Single-page applications may return the same page for many routes.

Example:

/random123
→ HTTP 200
→ Same application shell

This does not necessarily mean:

/random123 is a real application function

Compare response behavior.

Part 34 — Verify Endpoint Uniqueness

Compare:

• response length

• response title

• content type

• redirect

• application behavior

• authenticated state

Use this to distinguish real endpoints from generic fallbacks.

Part 35 — Deduplicate Endpoints

You may discover:

/profile

/profile/

/profile?tab=main

Decide whether these represent:

• same endpoint

• different state

• different function

Create a canonical path where appropriate.

Part 36 — Create the Deduplication Register

Discovered	Canonical	Reason
/profile/	/profile	Same function
/profile?tab=main	/profile	Same endpoint, parameterized state

Part 37 — Identify Authentication Boundaries

For each endpoint record:

Anonymous Access:
Yes / No

User Access:
Yes / No

Admin Access:
Yes / No

Build:

Endpoint	Anonymous	User	Admin
/	Yes	Yes	Yes
/profile	No	Yes	Yes
/admin	No	No	Yes

This is a baseline, not an authorization bypass test.

Part 38 — Create the Endpoint Role Matrix

Endpoint	Anonymous	User	Admin	Expected
/login	Yes	Yes	Yes	Public
/account	No	Yes	Yes	User+
/admin	No	No	Yes	Admin

Part 39 — Identify State-Changing Endpoints

Mark endpoints that:

Create

Update

Delete

Upload

Change Password

Change Email

Change Role

Submit Order

Transfer Funds

These deserve higher testing priority.

Part 40 — Build the State-Changing Endpoint Register

Endpoint	Method	Change	Priority
/profile/update	POST	User data	High
/password/change	POST	Credentials	High
/admin/user/role	POST	Privilege	Critical

Part 41 — Identify Sensitive Read Endpoints

Not all high-risk functionality changes data.

Examples:

/account

/export

/report

/admin/users

Sensitive information disclosure may occur through read-only functions too.

Part 42 — Build the Sensitive Data Endpoint Register

Endpoint	Data	Role	Priority
/profile	User PII	User	High
/reports	Business data	Admin	High

Part 43 — Identify Redirect Parameters

Look for:

next=

return=

redirect=

url=

Record them for later assessment.

Do not classify as an open redirect yet.

Part 44 — Identify URL-Receiving Parameters

Parameters that accept URLs may be relevant to later server-side assessment.

Examples:

url=

image_url=

callback=

webhook=

Record them.

Do not perform external interaction testing here.

Part 45 — Identify File Path-Like Parameters

Examples:

file=

path=

template=

document=

Record them as higher-priority inputs for later assessment.

Again:

Parameter Name ≠ Vulnerability

Part 46 — Identify Role or Permission Fields

Examples:

role

is_admin

permission

access_level

If observed in legitimate traffic, record them.

These become high-priority areas for authorization/business-logic assessment.

Part 47 — Build the High-Risk Parameter Register

Parameter	Endpoint	Reason	Future Lab
id	/order	Object access	Authorization
role	/profile	Privilege-related	Authorization
url	/preview	Server-side fetch	Server-Side
file	/upload	File handling	File Security

Part 48 — Create the Endpoint Classification Model

Classify each endpoint by function:

Authentication

Session

Account

Administrative

Search

File

API

Business Logic

Read

Write

Utility

Static

Legacy

Part 49 — Build the Master Endpoint Register

Use:

ID	Method	Endpoint	Auth	Role	Function	State Change	Priority
EP-001	GET	/login	No	Anonymous	Authentication	No	High
EP-002	POST	/login	No	Anonymous	Authentication	Yes	High
EP-003	GET	/profile	Yes	User	Account	No	High
EP-004	POST	/profile/update	Yes	User	Account	Yes	High
EP-005	GET	/admin	Yes	Admin	Admin	No	High

Part 50 — Prioritize Endpoint Testing

Use:

Exposure + User Control + Privilege + Data Sensitivity + State Change + Business Impact

Example:

/admin/user/role
   +
Administrative
   +
Privilege Change
   +
State Changing
   =
Very High Priority

Part 51 — Create the Endpoint Priority Matrix

Endpoint	Exposure	Privilege	Impact	Priority
/login	Public	Identity	High	High
/profile/update	Auth	User	Medium	High
/admin/user/role	Admin	Privilege	High	Very High

Part 52 — Create the Parameter Priority Matrix

Parameter	Type	Control	Security Relevance	Priority
q	Search	User	Input validation	Medium
id	Object ID	User	Authorization	High
role	Role	User/Unknown	Privilege	Very High
file	Upload	User	File security	High

Part 53 — Identify Discovery Gaps

Possible gaps:

No administrative account available.

API documentation missing.

Some endpoints visible only to another role.

Client-side resources are bundled.

Legacy functionality unclear.

One endpoint depends on out-of-scope service.

Record:

Gap	Impact	Follow-Up
No admin account	Admin surface incomplete	Obtain authorized test role
API docs absent	Possible missed endpoints	API discovery later

Part 54 — Build the Attack Surface Coverage Matrix

Area	Coverage
Public Endpoints	Complete/Partial
Authenticated Endpoints	Complete/Partial
Admin Endpoints	Complete/Partial
API Endpoints	Complete/Partial
Parameters	Complete/Partial
File Functions	Complete/Partial
Legacy Content	Complete/Partial

Part 55 — Preserve Discovery Evidence

Capture evidence for:

• endpoint source

• request

• response

• role

• status

• parameter

• content type

• verification outcome

Avoid collecting redundant screenshots where HTTP evidence is clearer.

Part 56 — Create the Evidence Register

Evidence ID	Description
EV-001	Seed endpoint inventory
EV-002	Form action discovery
EV-003	HTTP-discovered API endpoint
EV-004	Client-side route
EV-005	Admin endpoint verification
EV-006	Parameter inventory
EV-007	Role matrix

Part 57 — Create Discovery Observations

Example:

OBSERVATION ID:
OBS-001

TITLE:
Administrative User-Management Endpoint Identified

ENDPOINT:
/admin/users

EXPECTED ROLE:
Administrator

SECURITY RELEVANCE:
High-value authorization boundary.

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

FINDING:
No

Part 58 — Do Not Inflate Discovery into Findings

Do not write:

Finding:
Hidden admin endpoint discovered.

Severity:
Critical.

unless unauthorized access or another validated security issue exists.

Discovery is not exploitation.

Part 59 — Build the Final Attack Surface Map

Example:

                       Web Application
                              │
        ┌─────────────────────┼──────────────────────┐
        ▼                     ▼                      ▼
      Public             Authenticated             Admin
        │                     │                      │
   ┌────┴────┐          ┌─────┴──────┐        ┌─────┴─────┐
   ▼         ▼          ▼            ▼        ▼           ▼
 Login     Search    Profile       Orders   Users       Reports
   │         │          │            │
   ▼         ▼          ▼            ▼
 POST      q param   user_id      order_id

                        APIs
                         │
                 ┌───────┼───────┐
                 ▼       ▼       ▼
              Profile   Orders  Files

Part 60 — Mission Challenge

Complete:

WEB CONTENT, ENDPOINT & PARAMETER DISCOVERY

Assessment ID:

Analyst:

Date:


SCOPE

Application:

Base URL:

Authorized:
Yes / No

Excluded Systems:


SEED ENDPOINTS

Seed 01:

Source:

Seed 02:

Source:


VISIBLE CONTENT

Public Pages:

Authenticated Pages:

Administrative Pages:


FORM ACTIONS

Form 01:

Endpoint:

Method:

Form 02:

Endpoint:

Method:


HTTP-DISCOVERED ENDPOINTS

Endpoint 01:

Method:

Source:

Endpoint 02:

Method:

Source:


CLIENT-SIDE ROUTES

Route 01:

Verified:

Route 02:

Verified:


API ENDPOINTS

API 01:

Method:

Auth:

API 02:

Method:

Auth:


PARAMETERS

Query Parameters:

Body Parameters:

JSON Parameters:

Path Parameters:

Cookie Values:

Header Inputs:


OBJECT REFERENCES

Object 01:

Endpoint:

Parameter:

Object 02:

Endpoint:

Parameter:


FILE FUNCTIONALITY

Upload Endpoints:

Download Endpoints:

Export Endpoints:


ADMINISTRATIVE SURFACE

Admin Endpoint 01:

Expected Role:

Verified:

Admin Endpoint 02:

Expected Role:

Verified:


LEGACY CONTENT

Legacy Endpoint:

Status:

Relevance:


STATE-CHANGING ENDPOINTS

Endpoint 01:

Method:

Change:

Endpoint 02:

Method:

Change:


HIGH-RISK PARAMETERS

Parameter 01:

Reason:

Parameter 02:

Reason:

Parameter 03:

Reason:


DISCOVERY GAPS

Gap 01:

Impact:

Gap 02:

Impact:


COVERAGE

Public:
Complete / Partial

Authenticated:
Complete / Partial

Admin:
Complete / Partial

API:
Complete / Partial

Parameters:
Complete / Partial


FINAL ASSESSMENT

Endpoints Verified:

Parameters Identified:

High-Priority Endpoints:

High-Priority Parameters:

Attack Surface Updated:
Yes / No

Ready for Authentication Assessment:
Yes / No

What Not to Do

Do not:

Scan systems outside authorized scope

Treat every discovered path as real functionality

Treat every HTTP 200 as a valid endpoint

Treat a hidden route as a vulnerability

Assume an admin path means authorization bypass

Assume a parameter means injection

Assume an object ID means IDOR

Assume a URL parameter means SSRF

Assume a filename parameter means path traversal

Assume legacy content is vulnerable

Perform destructive enumeration

Use uncontrolled request volumes

Ignore authentication state

Ignore role context

Ignore generic application fallback pages

Ignore duplicate endpoints

Inflate reconnaissance observations into findings

The professional rule is:

Discovery expands your understanding of the application. Validation determines whether anything is insecure.

Professional Distinctions

Always distinguish:

Discovered Endpoint
      ≠
Verified Function

Verified Endpoint
      ≠
Vulnerable Endpoint

HTTP 200
      ≠
Real Unique Resource Automatically

Hidden Route
      ≠
Sensitive Information Exposure

Admin Path
      ≠
Authorization Bypass

Parameter
      ≠
Injection

Object ID
      ≠
IDOR

URL Parameter
      ≠
SSRF

File Parameter
      ≠
Path Traversal

Legacy Endpoint
      ≠
Exploitable Legacy Application

More Endpoints
      ≠
More Vulnerabilities

Evidence Requirements

Capture:

• assessment scope

• seed endpoint inventory

• visible content register

• form action register

• HTTP-discovered endpoint register

• client-side route register

• verification records

• API endpoint register

• query parameter register

• body parameter register

• JSON parameter register

• path parameter register

• object reference register

• upload endpoint register

• download endpoint register

• administrative endpoint register

• legacy content register

• deduplication register

• endpoint role matrix

• state-changing endpoint register

• sensitive data endpoint register

• high-risk parameter register

• Master Endpoint Register

• endpoint priority matrix

• parameter priority matrix

• discovery gaps

• coverage matrix

• final attack surface map

• evidence register

Mission Deliverables

Complete:

• scope reconfirmed

• seed endpoints imported

• visible content documented

• form actions discovered

• HTTP traffic reviewed

• backend endpoints identified

• client-side routes reviewed

• discovered endpoints verified

• endpoint states classified

• API paths mapped

• query parameters mapped

• body parameters mapped

• JSON parameters mapped

• path parameters mapped

• cookie/header inputs documented

• object identifiers identified

• upload endpoints documented

• download endpoints documented

• administrative surface mapped

• legacy functionality recorded

• generic fallback behavior considered

• endpoint duplicates removed

• role expectations mapped

• state-changing endpoints prioritized

• sensitive read endpoints prioritized

• redirect parameters documented

• URL-accepting parameters documented

• file/path-like parameters documented

• role/permission fields documented

• Master Endpoint Register completed

• parameter priority matrix completed

• discovery gaps documented

• attack-surface coverage assessed

• evidence preserved

• final attack surface map updated

Lab Report Template

# Lab 04 — Web Content, Endpoint & Parameter Discovery

## Executive Summary

## Mission Objective

## Authorization & Scope

## Seed Endpoints

## Visible Application Content

## Form Actions

## HTTP-Discovered Endpoints

## Client-Side Route Discovery

## Endpoint Verification

## Endpoint Classification

## API Surface

## Query Parameters

## Body Parameters

## JSON Parameters

## Path Parameters

## Cookie & Header Inputs

## Object References

## Upload Functionality

## Download Functionality

## Administrative Surface

## Legacy Content

## Error / Fallback Behavior

## Endpoint Deduplication

## Endpoint Role Matrix

## State-Changing Endpoints

## Sensitive Data Endpoints

## High-Risk Parameters

## Master Endpoint Register

## Endpoint Prioritization

## Parameter Prioritization

## Discovery Gaps

## Coverage Matrix

## Final Attack Surface Map

## Evidence Register

## Observations

## Limitations

## Areas for Further Testing

## Conclusion

Knowledge Check

Question 1 — Why is endpoint discovery important?

Because important application functionality may not appear in visible navigation but can still be part of the authorized attack surface.

Question 2 — Does HTTP 200 prove a unique endpoint exists?

No.

Some applications return generic pages or application shells for unknown routes.

Question 3 — Does discovering an admin endpoint prove a vulnerability?

No.

It identifies a high-value authorization boundary for later testing.

Question 4 — What is the purpose of a Master Parameter Register?

To organize user-controlled and security-relevant inputs by endpoint, location, and priority.

Question 5 — Why identify state-changing endpoints?

Because actions that modify users, data, privileges, or application state often carry higher security impact.

Question 6 — Does a URL parameter prove SSRF?

No.

It only identifies an input that may deserve server-side validation later.

Question 7 — Why deduplicate endpoints?

To prevent the same application function from appearing multiple times and distorting attack-surface coverage.

Question 8 — Why record endpoint roles?

Because later authorization testing depends on understanding expected access for anonymous, normal-user, and privileged roles.

Question 9 — What should happen to an endpoint that is discovered but not verified?

Keep it marked as Discovered / Pending Verification rather than treating it as confirmed functionality.

Question 10 — What is the central question?

“Have I identified enough of the application’s real endpoint and parameter surface that important functionality is unlikely to remain invisible to the rest of the assessment?”

Skills Achieved

After completing this lab, you should understand:

• content discovery

• endpoint discovery

• endpoint verification

• endpoint classification

• HTTP-derived discovery

• client-side route analysis

• API path discovery

• parameter discovery

• query/body/JSON/path parameter mapping

• object-reference mapping

• file-function mapping

• administrative-surface mapping

• legacy-content identification

• fallback-route analysis

• endpoint deduplication

• role-aware endpoint mapping

• state-changing endpoint identification

• endpoint prioritization

• parameter prioritization

• attack-surface coverage analysis

• discovery evidence management

Professional Takeaway

A weak discovery process looks like:

Run Discovery
      ↓
Collect Hundreds of Paths
      ↓
Assume They're Real
      ↓
Start Testing Randomly

A professional discovery process looks like:

Start with Known Endpoints
      ↓
Observe Normal Traffic
      ↓
Discover Additional Routes
      ↓
Verify Each Relevant Endpoint
      ↓
Identify Parameters
      ↓
Identify Roles
      ↓
Classify Function
      ↓
Remove Duplicates
      ↓
Identify High-Value Endpoints
      ↓
Prioritize Deeper Assessment

What’s Next?

➡️ Lab 05 — Authentication Security Assessment

In the next lab, you will move from discovering application entry points to assessing how the application establishes and protects user identity.

You will work with:

• login workflows

• authentication responses

• test accounts

• password policy

• account enumeration signals

• login failure behavior

• lockout/rate-control behavior

• password-reset workflows

• account recovery

• MFA behavior where available

• authentication state transitions

• error-message consistency

• security-control evidence

• reporting

The methodology becomes:

Map → Baseline → Compare → Validate Controls → Assess Impact → Evidence → Report

And the central question will be:

“Can an unauthorized user gain meaningful information about accounts, bypass expected authentication controls, or abuse account-recovery behavior within the authorized training application?”