Runbook 03 — Web Application Security Assessment

Purpose

Use this runbook after completing:

Runbook 02 — Reconnaissance and Attack Surface Discovery

At this stage, you should already know:

Which Applications Are In Scope

Which Assets Are High Priority

Which APIs Support the Application

Which Authentication Services Exist

Which Third Parties Must Be Avoided

The objective of this runbook is to move from:

Known Application

to:

Understood
      ↓
Mapped
      ↓
Tested
      ↓
Validated
Web Application

The operating principle is:

Understand First
      ↓
Model Security Boundaries
      ↓
Create Hypotheses
      ↓
Test Methodically
      ↓
Validate Minimally
      ↓
Document Clearly

When to Use This Runbook

Use this runbook:

• when beginning assessment of a newly discovered web application.

• when a high-priority web target is selected.

• after significant application changes.

• when new authenticated features are released.

• when new roles or business workflows appear.

• before deep authorization or business-logic testing.

• when comparing current and legacy versions of an application.

• when retesting a previously assessed web application.

Runbook Outcome

At completion, you should have:

Application Map

User Journey Map

Feature Inventory

Research Account Model

Role Matrix

Object Register

Request Register

API Feature Map

Security Boundary Map

Authorization Matrix

Workflow State Map

Testing Hypotheses

Vulnerability Candidates

Evidence Package

Assessment Summary

Required Inputs

Before starting, obtain the current:

Scope Register

Attack Surface Map

Asset Prioritization

Recon Hypotheses

Testing Restrictions

Third-Party Register

You should also have:

Dedicated Research Browser

Intercepting Proxy

Researcher-Controlled Accounts

Required Records

Create or update:

01 Application_Map.md

02 User_Journey.md

03 Feature_Inventory.csv

04 Research_Accounts.csv

05 Role_Matrix.csv

06 Object_Register.csv

07 Request_Register.csv

08 API_Feature_Map.csv

09 Security_Boundaries.md

10 Authorization_Matrix.csv

11 Workflow_State_Map.md

12 Security_Hypotheses.csv

13 Testing_Log.csv

14 Vulnerability_Candidates.csv

15 Evidence_Register.csv

16 Assessment_Summary.md

Phase 1 — Assessment Authorization Gate

Step 1 — Confirm Target Scope

Before opening the application for active testing, confirm:

Hostname Is In Scope

Application Is Not Excluded

Testing Method Is Allowed

Automation Limits Are Known

Third Parties Are Excluded

If any status is:

Unknown

stop and resolve it before proceeding.

Step 2 — Configure Proxy Scope

Include only:

Authorized Application

Authorized API

Authorized Authentication Services

Exclude:

Analytics

Payment Providers

Support Platforms

Advertising

Other Third Parties

Step 3 — Define Assessment Objective

Do not begin with:

Find Vulnerabilities

Use something specific, such as:

Understand and assess
the application's
authentication,
authorization,
file-sharing and
organization workflows.

Phase 2 — Prepare Research Identities

Step 4 — Create Controlled Accounts

Where supported, prepare:

Account A

Account B

For multi-tenant applications:

Tenant A
└── Account A

Tenant B
└── Account B

If role testing is required:

Tenant A
├── Standard Member
└── Organization Admin

Step 5 — Record Account Model

Create:

04 Research_Accounts.csv

with:

Account	Role	Tenant	Purpose	Status
Account A	Standard User	Tenant A	Owner testing	Active
Account B	Standard User	Tenant B	Cross-user testing	Active
Admin A	Org Admin	Tenant A	Role testing	Optional

Do not store passwords or live authentication tokens.

Phase 3 — Use the Application Normally

Step 6 — Establish Legitimate Usage

Before modifying requests, perform normal activities such as:

Register

Login

View Dashboard

Edit Profile

Create Resource

Upload File

Share Resource

Invite User

Change Settings

Logout

The objective is:

Understand
Application Behavior

Step 7 — Keep Proxy as Recorder

Initially use the proxy primarily to capture:

Requests

Responses

API Calls

Cookies

Object IDs

State Changes

Avoid unnecessary request manipulation during this phase.

Phase 4 — Build User Journey

Step 8 — Create User Journey Map

Create:

02 User_Journey.md

Example:

Visitor
      ↓
Registration
      ↓
Verification
      ↓
Login
      ↓
Dashboard
      ↓
Create Organization
      ↓
Create Project
      ↓
Upload File
      ↓
Share File
      ↓
Invite Member
      ↓
Account Management
      ↓
Logout

Step 9 — Identify Security-Critical Transitions

Highlight transitions such as:

Guest
      ↓
Authenticated

Member
      ↓
Admin

Private
      ↓
Shared

Active
      ↓
Revoked

Tenant A
      ↓
Tenant B

Phase 5 — Build Application Map

Step 10 — Inventory Application Areas

Create:

01 Application_Map.md

Example:

Application
│
├── Authentication
│   ├── Register
│   ├── Login
│   ├── Password Reset
│   └── Logout
│
├── Profile
│
├── Organizations
│   ├── Members
│   ├── Invitations
│   └── Roles
│
├── Projects
│
├── Files
│   ├── Upload
│   ├── Download
│   ├── Preview
│   └── Share
│
├── Developer
│   ├── API Keys
│   └── Integrations
│
└── Administration

Step 11 — Build Feature Inventory

Create:

03 Feature_Inventory.csv

with:

Feature	Area	Auth Required	Role	Object	Priority

Increase priority for:

Authentication

Private Data

Files

Sharing

Organizations

Administrative Functions

API Keys

Payments

Account Recovery

Phase 6 — Map Objects

Step 12 — Identify Application Objects

Examples:

User

Organization

Membership

Project

File

Message

Invitation

Share Link

API Key

Session

Step 13 — Create Object Register

Create:

06 Object_Register.csv

with:

Object	Identifier	Owner/Parent	Sensitivity	Operations

Step 14 — Map Object Relationships

Example:

User
      ↓ belongs to
Organization
      ↓ contains
Project
      ↓ contains
File

Another:

Organization
      ↓ creates
Invitation
      ↓ creates
Membership

Step 15 — Identify Nested Authorization

Ask:

Does the Project
Belong to the
Specified Organization?

Does the File
Belong to the
Specified Project?

Does the Member
Belong to the
Specified Tenant?

Many authorization weaknesses occur because one object is validated while its parent relationship is not.

Phase 7 — Map Roles

Step 16 — Identify Confirmed Roles

Examples:

Guest

Standard User

Member

Manager

Organization Admin

Platform Admin

Do not invent roles that are not observed.

Step 17 — Create Role Matrix

Create:

05 Role_Matrix.csv

Example:

Feature	Guest	User	Member	Admin
View Own Profile	No	Yes	Yes	Yes
Create Project	No	Yes	Yes	Yes
Invite Member	No	No	No	Yes
Change Role	No	No	No	Yes

Step 18 — Separate UI and Backend Authorization

Remember:

Hidden Button
      ≠
Protected Action

Record any privileged UI action for later backend validation.

Phase 8 — Map Requests

Step 19 — Map UI Actions to Backend Requests

For each important feature, identify:

UI Action
      ↓
HTTP Request
      ↓
Endpoint
      ↓
Object
      ↓
Security Decision

Example:

Download File
      ↓
GET /api/v2/files/{file_id}
      ↓
Can This User
Access This File?

Step 20 — Create Request Register

Create:

07 Request_Register.csv

with:

Feature	Method	Endpoint	Object	Role	Security Decision

Step 21 — Save Baselines

For important operations save known-good requests:

Authentication/

Authorization/

Projects/

Files/

Organizations/

Developer/

Redact authentication material.

Phase 9 — Map API Features

Step 22 — Create API Feature Map

Create:

08 API_Feature_Map.csv

with:

UI Feature	API Endpoint	Method	Object	Expected Control

Example:

| View Project | /projects/{id} | GET | Project | Object authorization |
| Change Role | /members/{id} | PATCH | Membership | Role authorization |
| Download File | /files/{id} | GET | File | Ownership/access check |

Step 23 — Identify Object Identifiers

Look for:

user_id

organization_id

project_id

file_id

member_id

invite_id

token

Record where each identifier appears.

Phase 10 — Identify Client-Controlled Values

Step 24 — Record Client-Supplied Security-Relevant Fields

Examples:

owner_id

organization_id

role

status

permissions

price

user_id

Ask:

Should the Client
Be Allowed to
Control This?

Step 25 — Identify Expected Server-Controlled Fields

Typical server-controlled values include:

Owner

Tenant

Role

Privilege

Account Status

Created By

These observations become later hypotheses.

Phase 11 — Map Security Boundaries

Step 26 — Create Security Boundary Map

Create:

09 Security_Boundaries.md

Include at least:

Guest
      ↓
Authenticated User

User A
      ↓
User B

Tenant A
      ↓
Tenant B

Member
      ↓
Admin

Browser
      ↓
Backend

Application
      ↓
File Storage

Step 27 — Horizontal Boundary

Expected:

User A
Can Access
User A Resources

but:

User A
Should Not Access
User B Resources

unless explicitly shared.

Step 28 — Vertical Boundary

Expected:

Member
      ≠
Administrator

Privileged actions must be enforced server-side.

Step 29 — Tenant Boundary

For SaaS:

Tenant A
      ≠
Tenant B

even when user roles are identical.

Phase 12 — Build Authorization Matrix

Step 30 — Create Expected Authorization Decisions

Create:

10 Authorization_Matrix.csv

Example:

Action	Own Object	Other User	Other Tenant	Member	Admin
View Project	Allow	Deny	Deny	Depends	Allow
Edit Project	Allow	Deny	Deny	Depends	Allow
Download File	Allow	Deny	Deny	Depends	Allow
Change Role	N/A	N/A	N/A	Deny	Allow

The matrix documents:

Expected
Security Behavior

before testing begins.

Phase 13 — Map Authentication Surface

Step 31 — Identify Authentication Workflows

Map:

Registration

Login

Logout

Password Change

Password Reset

MFA

Recovery

Session Creation

Step 32 — Record Authentication State

Identify whether the application uses:

Session Cookie

Bearer Token

JWT

Refresh Token

Record only enough for mapping.

Detailed authentication testing should follow the dedicated authentication runbook when needed.

Phase 14 — Map File Workflows

Step 33 — Map Upload

Document:

Select File
      ↓
Upload
      ↓
File Object
      ↓
Storage

Record:

Upload Endpoint

File Identifier

Owner

Project/Tenant Relationship

Processing

Step 34 — Map Download

Document:

User
      ↓
Application
      ↓
Authorization
      ↓
File Access

Step 35 — Map Sharing

Document:

Owner
      ↓
Create Share
      ↓
Token / Link
      ↓
Recipient Access
      ↓
Revoke

Create future questions around:

Ownership

Expiration

Revocation

Token Binding

Phase 15 — Map Invitation and Membership Workflows

Step 36 — Map Invitations

Example:

Admin
      ↓
Create Invitation
      ↓
Invitation Token
      ↓
Recipient Accepts
      ↓
Membership Created

Record:

Assigned Role

Tenant

Recipient

Expiry

Revocation

Step 37 — Map Role Changes

Document:

Actor

Target Member

Old Role

New Role

Endpoint

Expected Permission

Phase 16 — Map Application States

Step 38 — Identify State Machines

Examples:

Invitation:
Pending
Accepted
Revoked
Expired

Project:
Active
Archived
Deleted

Share Link:
Active
Revoked
Expired

Step 39 — Create State Map

Create:

11 Workflow_State_Map.md

Step 40 — Create State Security Questions

Examples:

Can Revoked Link
Still Work?

Can Expired Invitation
Still Be Accepted?

Can Removed Member
Still Access Resources?

Can Archived Object
Still Be Modified?

Phase 17 — Build Security Hypotheses

Step 41 — Create Hypothesis Register

Create:

12 Security_Hypotheses.csv

with:

ID	Feature	Observation	Hypothesis	Priority	Status

Step 42 — Use Hypothesis Formula

Use:

Because
[Observation]

I Believe
[Control Failure]

May Allow
[Capability]

Step 43 — Example: Object Authorization

Because project_id
is supplied by the client,

I believe object ownership
may not be enforced
server-side,

which may allow another
authenticated user to
access the project.

Step 44 — Example: Vertical Authorization

Because role changes
are performed through
a normal API request,

I believe a standard member
may be able to invoke
the endpoint directly

if role authorization
is enforced only by the UI.

Step 45 — Example: File Sharing

Because file access
can occur through
share links,

I believe revoked links
may remain usable

if revocation state
is not checked at
access time.

Phase 18 — Begin Controlled Testing

Step 46 — Follow Baseline-Driven Testing

Use:

Known-Good Baseline
      ↓
Change One Variable
      ↓
Repeat Request
      ↓
Compare

Step 47 — Record Every Test

Create:

13 Testing_Log.csv

with:

Date	Hypothesis	Test	Expected	Observed	Result

Record both:

Positive Results

Negative Results

Phase 19 — Authorization Testing

Step 48 — Horizontal Authorization

Use:

Account A
      ↓
Create Object A

Account B
      ↓
Request Object A

Expected:

Denied

unless explicitly shared.

Step 49 — Cross-Tenant Authorization

Use:

Tenant A Resource
      ↓
Tenant B Account

Expected:

Denied

Step 50 — Vertical Authorization

Use controlled low-privilege and admin accounts where available.

Compare:

Admin Request

against:

Member Request

Change only the authentication context where possible.

Step 51 — Stop Condition

If one controlled unauthorized request proves the boundary failure:

Capture Evidence
      ↓
Stop

Do not enumerate additional unrelated resources.

Phase 20 — Input Validation Assessment

Step 52 — Identify Input Context

Before testing an input, determine whether it is used as:

Text

Number

Object ID

URL

File Name

Path

Search Query

Structured JSON

Step 53 — Test Contextually

Do not run random payload lists.

Use:

Input Context
      ↓
Security Hypothesis
      ↓
Minimal Test

Step 54 — Prefer Non-Destructive Validation

For suspicious interpreter behavior, prefer:

Controlled Errors

Harmless Response Differences

Researcher-Controlled Callbacks

Test Objects

Avoid:

Data Destruction

Bulk Data Extraction

System Disruption

Phase 21 — File Security Assessment

Step 55 — Validate Ownership

Using controlled files:

Account A
      ↓
File A

Account B
      ↓
Request File A

Expected:

Denied

unless sharing is intended.

Step 56 — Validate Share State

For controlled share links:

Create
      ↓
Access
      ↓
Revoke
      ↓
Access Again

Expected after revoke:

Denied

Step 57 — Avoid Sensitive Files

Never use:

Customer Files

Production Secrets

System Files

to prove access control.

Phase 22 — Business Logic Assessment

Step 58 — Understand Expected Workflow

Example:

Invite Member
      ↓
Accept Invitation
      ↓
Membership Created

or:

Create Order
      ↓
Pay
      ↓
Complete

Step 59 — Identify Rules

Examples:

Only Admin Can Change Roles

Revoked Invitation Cannot Be Accepted

User Cannot Approve Own Restricted Action

Price Must Be Server-Controlled

Step 60 — Test One Rule at a Time

Ask:

Can Step Be Skipped?

Can State Be Reordered?

Can Restricted Value
Be Changed?

Can Old State
Be Reused?

Use controlled objects and accounts.

Phase 23 — Candidate Management

Step 61 — Create Candidate Register

Create:

14 Vulnerability_Candidates.csv

with:

ID	Hypothesis	Observation	Evidence	Status

Use:

Needs Validation

False Positive

Confirmed

Reported

Step 62 — Do Not Promote Too Early

Remember:

Unexpected Behavior
      ↓
Candidate
      ↓
Validation
      ↓
Finding

Phase 24 — Vulnerability Validation

Step 63 — Validate Reproducibility

Ask:

Can It Be Repeated?

Under Which Account?

Under Which Role?

Against Which Object?

Under Which State?

Step 64 — Identify Broken Boundary

Possible boundaries:

Authentication

Object Authorization

Tenant Isolation

Role Authorization

Workflow State

File Ownership

Client/Server Trust

Step 65 — Identify Capability

Determine what the attacker gains:

Read

Modify

Delete

Share

Assume Role

Perform Restricted Action

Step 66 — Separate Observed and Potential Impact

Observed:

Account B accessed
Account A's controlled file.

Potential:

The same missing
ownership control may expose
other user files.

Do not present potential impact as proven.

Phase 25 — Evidence Collection

Step 67 — Create Evidence Folder

For each confirmed issue:

Evidence/
└── FIND-001/
    ├── 01-baseline-request.txt
    ├── 02-baseline-response.txt
    ├── 03-test-request.txt
    ├── 04-test-response.txt
    ├── 05-screenshot.png
    └── 06-timeline.md

Step 68 — Create Evidence Register

Create:

15 Evidence_Register.csv

with:

Evidence	Finding	Purpose	Redacted

Step 69 — Redact Sensitive Information

Remove:

Passwords

Session Cookies

Bearer Tokens

API Keys

Private Data

Phase 26 — Stop Conditions

Stop immediately if:

Real Customer Data Appears

Unexpected Administrative
Access Is Obtained

Production Secrets Appear

Out-of-Scope Systems Are Reached

Operational Impact Occurs

Also stop once:

Minimum Evidence
Required to Prove
the Vulnerability
Has Been Collected

Phase 27 — Assessment Summary

Step 70 — Create Assessment Summary

Create:

16 Assessment_Summary.md

Include:

Target

Assessment Objective

Accounts Used

Application Areas Mapped

Objects

Roles

Security Boundaries

Workflows Tested

Hypotheses Tested

Secure Behaviors

Candidates

Confirmed Findings

Evidence

Recommended Next Actions

Operational Decision Tree

Use:

Application Selected
      ↓
Scope Check
      ↓
Normal Usage
      ↓
Map Features
      ↓
Map Roles
      ↓
Map Objects
      ↓
Capture Requests
      ↓
Map Boundaries
      ↓
Create Hypotheses
      ↓
Test Baseline
      ↓
Modify One Variable
      ↓
Unexpected?
     / \
   No   Yes
   ↓     ↓
Record Candidate
        ↓
     Reproduce
        ↓
     Boundary Broken?
       / \
     No   Yes
     ↓     ↓
  Reject Validate Impact
             ↓
          Evidence
             ↓
            Stop

High-Priority Web Security Questions

During assessment, repeatedly ask:

Can User A
Access User B?

Can Tenant A
Access Tenant B?

Can Member
Act as Admin?

Can Client-Controlled
Values Affect Ownership
or Privilege?

Can Revoked
Access Still Work?

Can Restricted
Workflow States
Be Reused?

Does the Backend
Revalidate Every
Sensitive Action?

Common Failure 1 — Testing Before Understanding

Avoid:

Find Parameter
      ↓
Send Payload

before understanding:

Purpose

Owner

Role

State

Expected Behavior

Common Failure 2 — Treating Pages as the Security Model

Security decisions usually occur around:

Objects

APIs

Roles

States

Relationships

not simply pages.

Common Failure 3 — Trusting the UI

Remember:

Disabled Field
      ≠
Server-Side Validation

Hidden Button
      ≠
Server-Side Authorization

Common Failure 4 — No Object Ownership Model

Testing file_id without knowing:

Owner

Tenant

Parent Project

Sharing State

can produce incorrect conclusions.

Common Failure 5 — No Baseline

Always preserve:

Legitimate
Expected Behavior

before manipulating requests.

Common Failure 6 — Random Payload Testing

Avoid:

500 Payloads
      ↓
No Context

Use:

Security Question
      ↓
Relevant Test

Common Failure 7 — Using Real Customer Resources

Authorization testing should use:

Account A

Account B

Controlled Objects

Common Failure 8 — Over-Testing Confirmed Findings

Once a controlled test proves:

Security Boundary Failed

do not continue simply to increase the amount of exposed data.

Common Failure 9 — Ignoring Negative Results

Secure behavior is useful information.

Record:

Hypothesis Rejected

so it is not repeatedly tested.

Common Failure 10 — Overstating Impact

If you prove:

Read One Test File

do not claim:

Full Platform Compromise

without a connected, demonstrated attack path.

Assessment Quality Checklist

Before closing this runbook, confirm:

[ ] Scope validated

[ ] Proxy scope configured

[ ] Research accounts prepared

[ ] User journey mapped

[ ] Features inventoried

[ ] Roles documented

[ ] Objects documented

[ ] Object relationships mapped

[ ] Baseline requests saved

[ ] API features mapped

[ ] Security boundaries defined

[ ] Authorization matrix created

[ ] Application states mapped

[ ] File workflows mapped

[ ] Invitation workflows mapped

[ ] Business rules documented

[ ] Security hypotheses created

[ ] Tests logged

[ ] Negative results recorded

[ ] Vulnerability candidates tracked

[ ] Confirmed findings reproduced

[ ] Evidence redacted

[ ] Stop conditions followed

[ ] Assessment summary completed

Runbook Success Criteria

This runbook is complete when you can clearly explain:

How the Application Works

Which Roles Exist

Which Objects Exist

Who Owns Them

How Objects Relate

Which API Requests
Perform Important Actions

Which Security Boundaries
Must Be Enforced

Which Hypotheses
Were Tested

Which Behaviors
Were Secure

Which Findings
Were Confirmed

and

What Evidence
Supports Each Finding

Professional Web Assessment Workflow

Use:

Scope
      ↓
Normal Usage
      ↓
User Journey
      ↓
Features
      ↓
Roles
      ↓
Objects
      ↓
Relationships
      ↓
Requests
      ↓
Security Boundaries
      ↓
Expected Controls
      ↓
Hypotheses
      ↓
Controlled Testing
      ↓
Validation
      ↓
Evidence
      ↓
Reporting

Key Takeaways

Remember:

Page
      ≠
Security Boundary

Hidden Button
      ≠
Authorization

Object ID
      ≠
Object Ownership

Client Validation
      ≠
Server Validation

Unexpected Response
      ≠
Confirmed Vulnerability

Potential Impact
      ≠
Observed Impact

More Exploitation
      ≠
Better Evidence

A professional web application assessment is built around:

Architecture

      +

Users

      +

Roles

      +

Objects

      +

Relationships

      +

States

      +

Security Boundaries

      +

Evidence

The goal is not:

Try Every Payload

The goal is:

Understand
Which Security
Decision Should Occur

and

Verify Whether
the Backend
Enforces It

Runbook Output

At completion, update or archive:

01 Application_Map.md

02 User_Journey.md

03 Feature_Inventory.csv

04 Research_Accounts.csv

05 Role_Matrix.csv

06 Object_Register.csv

07 Request_Register.csv

08 API_Feature_Map.csv

09 Security_Boundaries.md

10 Authorization_Matrix.csv

11 Workflow_State_Map.md

12 Security_Hypotheses.csv

13 Testing_Log.csv

14 Vulnerability_Candidates.csv

15 Evidence_Register.csv

16 Assessment_Summary.md

Runbooks Complete

You now have the planned core operational runbooks for the Bug Bounty Hunter Learning Path:

Runbook 01
Bug Bounty Program Intake
and Scope Validation

      ↓

Runbook 02
Reconnaissance and
Attack Surface Discovery

      ↓

Runbook 03
Web Application
Security Assessment

Together they create a practical end-to-end operating model:

Program Intake
      ↓
Authorization
      ↓
Scope
      ↓
Reconnaissance
      ↓
Attack Surface
      ↓
Application Mapping
      ↓
Security Boundaries
      ↓
Hypothesis-Driven Testing
      ↓
Validation
      ↓
Evidence
      ↓
Reporting

Learning Path Operational Completion

The complete progression is now:

Bug Bounty Hunter
Learning Modules
      ↓
5 Hands-On Labs
      ↓
3 Core Operational Runbooks
      ↓
Portfolio Projects
      ↓
Independent Security Research

The final professional principle for this learning path is:

Know Your Scope

Understand the Target

Map the Security Model

Test with Purpose

Validate Minimally

Preserve Evidence

Communicate Clearly

➡️ Bug Bounty Hunter Learning Path — Labs and Core Runbooks Complete