Lab 04 — Web Application Mapping and Security Boundary Analysis

Welcome to:

Lab 04 — Web Application Mapping and Security Boundary Analysis

In Lab 03, you built a validated and prioritized attack surface.

You now know:

Which Assets Exist

Which Applications Are Live

Which APIs Are Exposed

Which Systems Are High Priority

Which Assets Are Third Party

The next step is to move inside the primary application and understand:

How the Application
Actually Works

A common mistake in Bug Bounty hunting is to begin testing before understanding:

Users

Roles

Objects

Features

Workflows

Trust Relationships

Professional research should instead follow:

Use Application Normally
      ↓
Map Features
      ↓
Map Objects
      ↓
Map Roles
      ↓
Capture Requests
      ↓
Identify Security Boundaries
      ↓
Create Hypotheses
      ↓
Begin Testing

Your mission in this lab is to build a complete security model of the fictional NovaCloud application before attempting vulnerability exploitation.

Mission Information

Your Role

You are operating as a:

Bug Bounty Hunter

Application Security Researcher

continuing research against:

NovaCloud Security Research Program

Your primary target is:

app.novacloud.test

with supporting API traffic through:

api.novacloud.test

You will use only:

Researcher-Controlled Accounts

Researcher-Controlled Objects

Authorized Training Assets

Mission Objective

By the end of this lab, you should be able to explain:

Who Uses the Application?

Which Roles Exist?

Which Objects Exist?

Who Owns Each Object?

Which Features Exist?

Which APIs Power Them?

Which Security Boundaries Exist?

Where Must Authorization
Be Enforced?

Lab Objectives

By completing this lab, you will learn how to:

• use a web application from a legitimate user perspective.

• map user journeys.

• identify authentication workflows.

• identify application roles.

• identify tenant relationships.

• map application features.

• identify backend objects.

• document object ownership.

• capture baseline HTTP requests.

• map UI actions to API requests.

• identify object identifiers.

• understand role-based access.

• build authorization matrices.

• identify horizontal trust boundaries.

• identify vertical trust boundaries.

• identify tenant boundaries.

• identify client-to-server trust boundaries.

• map file and sharing workflows.

• map invitation workflows.

• understand state transitions.

• identify business logic assumptions.

• build structured security hypotheses.

• create a testing backlog for later labs.

Prerequisites

You should have completed:

Lab 01 — Build Your Professional Bug Bounty Research Environment

Lab 02 — Bug Bounty Program Scope Analysis and Target Prioritization

Lab 03 — Reconnaissance and Attack Surface Mapping

You should also understand:

HTTP

Sessions

Cookies

APIs

Authentication

Authorization

Basic Web Application Architecture

Lab Scenario

NovaCloud provides a multi-tenant collaboration platform.

Users can:

Register

Login

Create Organizations

Invite Members

Create Projects

Upload Files

Share Files

Manage Profiles

Generate API Keys

The application architecture is:

Browser
      ↓
app.novacloud.test
      ↓
api.novacloud.test
      ↓
Application Services
      ↓
Database / File Storage

Your task is not to exploit anything yet.

Your task is to build the application security model.

Lab Deliverables

By the end of this lab, create:

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 Application_Hypotheses.csv

13 Testing_Backlog.csv

14 Application_Mapping_Summary.md

Part 1 — Prepare Research Accounts

For this lab create:

Account A

Account B

If the training application supports organizations, create:

Tenant A

Tenant B

Recommended structure:

Tenant A
├── Account A
└── Project A

Tenant B
├── Account B
└── Project B

Part 2 — Create Research Account Register

Create:

04 Research_Accounts.csv

Use:

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

Do not place passwords or live tokens in this file.

Part 3 — Start as a Normal User

Do not immediately open the proxy repeater and modify requests.

First use the application normally.

Perform:

Register

Verify Account

Login

View Dashboard

Edit Profile

Create Organization

Create Project

Upload File

Share File

Invite Member

Logout

Observe:

What Changes?

What Objects Are Created?

Which Roles Matter?

Which Requests Occur?

Part 4 — Build the User Journey

Create:

02 User_Journey.md

Example:

Visitor
      ↓
Register
      ↓
Email Verification
      ↓
Login
      ↓
Dashboard
      ↓
Create Organization
      ↓
Create Project
      ↓
Upload File
      ↓
Share File
      ↓
Invite Member
      ↓
Manage Account
      ↓
Logout

Part 5 — Why User Journey Mapping Matters

Security vulnerabilities often occur between:

Steps

not only inside individual pages.

For example:

Invite User
      ↓
Assign Role
      ↓
Accept Invitation

may contain security assumptions that are invisible if you inspect only:

Invite Page

Part 6 — Build Application Map

Create:

01 Application_Map.md

Example:

NovaCloud Application
│
├── Authentication
│   ├── Registration
│   ├── Login
│   ├── Password Reset
│   ├── Session
│   └── Logout
│
├── Profile
│   ├── View Profile
│   └── Edit Profile
│
├── Organizations
│   ├── Create Organization
│   ├── View Organization
│   ├── Invite Members
│   ├── Change Roles
│   └── Remove Members
│
├── Projects
│   ├── Create Project
│   ├── View Project
│   ├── Edit Project
│   ├── Delete Project
│   └── Share Project
│
├── Files
│   ├── Upload
│   ├── Download
│   ├── Preview
│   ├── Share
│   └── Delete
│
├── API
│   ├── Profile
│   ├── Projects
│   ├── Files
│   └── Invitations
│
└── Developer
    ├── API Keys
    └── Integrations

Part 7 — Create Feature Inventory

Create:

03 Feature_Inventory.csv

Use:

Feature	Area	Authentication	Role	Primary Object	Priority
Login	Authentication	No	Guest	Session	High
Edit Profile	Profile	Yes	User	User	Medium
Create Project	Projects	Yes	User	Project	High
Upload File	Files	Yes	User	File	High
Invite Member	Organization	Yes	Admin	Invitation	High
Change Role	Organization	Yes	Admin	Membership	High
Generate API Key	Developer	Yes	User	API Key	High

Part 8 — Identify Application Objects

Objects are one of the most important concepts in authorization testing.

NovaCloud may contain:

User

Organization

Membership

Project

File

Invitation

Share Link

API Key

Session

Part 9 — Create Object Register

Create:

06 Object_Register.csv

Use:

Object	Identifier	Owner / Parent	Sensitivity	Operations
User	user_id	User	High	Read / Update
Organization	org_id	Members	High	CRUD
Project	project_id	Organization	High	CRUD
File	file_id	Project/User	High	CRUD / Share
Invitation	invite_id	Organization	Medium	Create / Accept / Revoke
Share Link	token/link_id	File	High	Create / Revoke
API Key	key_id	User	High	Create / Revoke

Part 10 — Identify Object Relationships

Create relationships such as:

User
      ↓ belongs to
Organization
      ↓ contains
Project
      ↓ contains
File

Another:

Organization
      ↓ creates
Invitation
      ↓ creates
Membership

Another:

File
      ↓ creates
Share Link

Part 11 — Why Relationships Matter

Authorization may correctly validate:

Project ID

but fail to validate:

Project
belongs to
Organization

This creates opportunities for:

Nested Object
Authorization Failure

Part 12 — Map Object Ownership

Example:

Tenant A
│
├── Account A
├── Project A
└── File A

Tenant B
│
├── Account B
├── Project B
└── File B

This gives you controlled ownership boundaries for future testing.

Part 13 — Identify Roles

Possible roles include:

Guest

Standard User

Organization Member

Organization Admin

Platform Admin

Your training environment may expose only some of these.

Record only confirmed roles.

Part 14 — Create Role Matrix

Create:

05 Role_Matrix.csv

Example:

Feature	Guest	User	Org Member	Org Admin
Login	Yes	N/A	N/A	N/A
View Own Profile	No	Yes	Yes	Yes
Create Project	No	Yes	Yes	Yes
Invite Member	No	No	No	Yes
Change Member Role	No	No	No	Yes
View Organization	No	Depends	Yes	Yes

Part 15 — UI Permission vs Server Permission

Important principle:

Button Hidden
      ≠
Action Protected

For example:

Standard User

may not see:

Change Role

button.

But later testing must verify whether the backend actually blocks:

Role Change API Request

Part 16 — Configure Proxy

Use your dedicated research browser.

Route:

Browser
      ↓
Intercepting Proxy
      ↓
NovaCloud

Configure scope for:

app.novacloud.test

api.novacloud.test

authorized lab subdomains

Exclude known third-party services.

Part 17 — Browse with Interception Off Initially

Use the proxy primarily as:

Recorder

while navigating normally.

Allow requests to flow and inspect:

HTTP History

This helps you understand application behavior without constantly interrupting the workflow.

Part 18 — Map UI Actions to Requests

For each feature, identify the backend request.

Example:

Click:
Create Project
      ↓
Request:
POST /api/v2/projects

Another:

Click:
Open File
      ↓
Request:
GET /api/v2/files/{file_id}

Part 19 — Create Request Register

Create:

07 Request_Register.csv

Use:

Feature	Method	Endpoint	Object	Auth	Role
View Profile	GET	/api/v2/profile	User	Yes	User
Create Project	POST	/api/v2/projects	Project	Yes	User
View Project	GET	/api/v2/projects/{id}	Project	Yes	User
Upload File	POST	/api/v2/files	File	Yes	User
Download File	GET	/api/v2/files/{id}	File	Yes	User
Invite User	POST	/api/v2/invitations	Invitation	Yes	Admin

Part 20 — Save Baseline Requests

For important features save clean baseline requests.

Examples:

05-Requests/
│
├── Authentication/
│   ├── login.txt
│   └── logout.txt
│
├── Projects/
│   ├── create-project.txt
│   └── view-project.txt
│
├── Files/
│   ├── upload-file.txt
│   └── download-file.txt
│
└── Organizations/
    ├── invite-member.txt
    └── change-role.txt

Redact authentication material in saved copies.

Part 21 — Why Baselines Matter

Future tests will follow:

Known-Good Request
      ↓
Modify One Variable
      ↓
Compare Behavior

Without a baseline, you may not know whether:

Unexpected Response

was caused by your test or normal application state.

Part 22 — Identify Object Identifiers

Look for identifiers in:

URL

JSON Body

Query Parameters

Headers

API Responses

Examples:

user_id

org_id

project_id

file_id

invite_id

Part 23 — Identifier Example

Request:

GET /api/v2/projects/2001 HTTP/1.1
Host: api.novacloud.test
Authorization: Bearer <TOKEN>

Potential object:

Project 2001

Record:

Identifier Type:
project_id

Part 24 — Do Not Modify IDs Yet

This lab focuses on:

Mapping

not:

Authorization Exploitation

Simply document where identifiers appear.

Part 25 — Map API Features

Create:

08 API_Feature_Map.csv

Use:

UI Feature	API Endpoint	Method	Object	Security Decision
View Project	/projects/{id}	GET	Project	Can user read project?
Rename Project	/projects/{id}	PATCH	Project	Can user modify project?
Download File	/files/{id}	GET	File	Can user access file?
Invite Member	/invitations	POST	Invitation	Can user invite members?
Change Role	/members/{id}	PATCH	Membership	Can user assign role?

Part 26 — Map Authentication Flow

Document:

Registration
      ↓
Verification
      ↓
Login
      ↓
Session Creation
      ↓
Authenticated Requests
      ↓
Logout

Part 27 — Identify Session Mechanism

Determine whether the application uses:

Session Cookie

Bearer Token

JWT

Other Token

Do not attempt to break it yet.

Record:

Where Is It Sent?

Cookie or Header?

Does It Change After Login?

Part 28 — Map Logout Behavior

Observe normal behavior:

Authenticated
      ↓
Logout
      ↓
Login Page

Record whether the browser:

Removes Cookie

Changes Token

Redirects

Actual revocation validation comes in later labs.

Part 29 — Map Password Reset

Without attacking it, document:

Request Reset
      ↓
Receive Reset Mechanism
      ↓
Reset Password
      ↓
Login

Identify:

Endpoints

Tokens

State Changes

Part 30 — Map Organization Workflow

Example:

Create Organization
      ↓
Become Admin
      ↓
Invite Member
      ↓
Member Accepts
      ↓
Membership Created

Part 31 — Map Invitation Workflow

Create:

Admin
      ↓
Creates Invitation
      ↓
Invite ID / Token
      ↓
Invitee
      ↓
Accepts
      ↓
Membership

This creates future questions around:

Token Binding

Role Assignment

Expiration

Replay

Tenant Binding

Part 32 — Map File Workflow

Document:

Select File
      ↓
Upload Request
      ↓
File Object Created
      ↓
Storage
      ↓
File Listed
      ↓
Download / Preview

Part 33 — Map File Sharing

Example:

File Owner
      ↓
Create Share Link
      ↓
Share Token
      ↓
Recipient
      ↓
Access File

Identify:

Who Creates Link?

What Object Is Linked?

Can Link Be Revoked?

Does It Expire?

Do not test weaknesses yet.

Part 34 — Map Project Workflow

Document:

Create Project
      ↓
Project ID
      ↓
Add Members
      ↓
Create Files
      ↓
Update Project
      ↓
Archive / Delete

Part 35 — Map Developer API Key Workflow

If available:

User
      ↓
Generate API Key
      ↓
Key Created
      ↓
API Access
      ↓
Revoke Key

Security questions for later:

What Permissions?

What Scope?

What Happens After Revocation?

Part 36 — Identify Client-Controlled Values

Look for fields such as:

user_id

org_id

project_id

role

owner_id

status

price

permissions

Ask:

Should the Client
Control This?

Do not modify them yet.

Part 37 — Identify Server-Controlled Values

Likely server-controlled values include:

Created By

Role

Owner

Tenant

Account Status

Internal Permissions

This distinction creates future mass-assignment and authorization hypotheses.

Part 38 — Map Security Boundaries

Create:

09 Security_Boundaries.md

Begin with:

# Security Boundaries

## Boundary 1 — Guest → Authenticated User

Control:
Authentication

Sensitive Functions:
Profile
Projects
Files
Organizations

## Boundary 2 — User A → User B

Control:
Object-Level Authorization

Objects:
Profile
Projects
Files

## Boundary 3 — Tenant A → Tenant B

Control:
Tenant Isolation

Objects:
Organizations
Projects
Files
Memberships

## Boundary 4 — Member → Organization Admin

Control:
Role-Based Authorization

Functions:
Invite Member
Change Role
Remove Member

## Boundary 5 — Browser → API

Control:
Server-Side Validation

Risk:
Client values must not be trusted.

## Boundary 6 — Application → File Storage

Control:
Backend Authorization

Risk:
Signed or direct file access must
remain bound to authorized objects.

Part 39 — Horizontal Security Boundary

Horizontal authorization concerns users with similar privilege.

Example:

User A
      ↓
User B's File

The expected control is:

Object-Level
Authorization

Part 40 — Vertical Security Boundary

Vertical authorization concerns:

Lower Privilege
      ↓
Higher Privilege

Example:

Organization Member
      ↓
Organization Admin Function

Part 41 — Tenant Boundary

Multi-tenant SaaS applications must enforce:

Tenant A
      ≠
Tenant B

even when users have equivalent roles.

Part 42 — Client/Server Boundary

The browser is:

User-Controlled

Therefore the backend should not trust:

Hidden Form Fields

Disabled Buttons

Client-Side Roles

Object IDs

Client-Side Validation

without server-side checks.

Part 43 — Build Authorization Matrix

Create:

10 Authorization_Matrix.csv

Example:

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

At this stage these are:

Expected
Security Decisions

Later labs will validate them.

Part 44 — Why Expected Decisions Matter

You cannot identify:

Authorization Failure

unless you first know:

What Authorization
Should Have Happened

Part 45 — Map Application States

Many objects have states.

Examples:

Invitation:
Pending
Accepted
Revoked
Expired

Project:
Active
Archived
Deleted

Account:
Active
Suspended
Disabled

Part 46 — Create Workflow State Map

Create:

11 Workflow_State_Map.md

Example:

# Invitation

Created
      ↓
Pending
      ↓
Accepted

Alternative:
Pending
      ↓
Revoked

Alternative:
Pending
      ↓
Expired

Part 47 — State Security Questions

Future questions may include:

Can Revoked Invitation
Be Accepted?

Can Expired Link
Still Work?

Can Archived Project
Be Modified?

Can Removed Member
Still Access Resources?

Part 48 — Identify Business Rules

Document expected rules such as:

Only Organization Admin
Can Change Roles

Only Authorized Members
Can Access Project Files

Revoked Share Links
Should Stop Working

Deleted API Keys
Should No Longer Authenticate

Part 49 — Build Security Assumption List

Create notes such as:

ASSUMPTION-001

The backend assumes
project_id belongs to
the authenticated user's tenant.

ASSUMPTION-002

Only organization admins
can submit role changes.

ASSUMPTION-003

File download authorization
occurs before generating
storage access.

These become later hypotheses.

Part 50 — Convert Mapping into Hypotheses

Create:

12 Application_Hypotheses.csv

Use:

ID	Feature	Observation	Hypothesis	Priority

Part 51 — Hypothesis 1: Project Authorization

Observation:

Project ID
is present
in URL.

Hypothesis:

A standard user may be able
to access another user's
project by substituting a
different project identifier
if object authorization is
not enforced server-side.

Priority:

High

Part 52 — Hypothesis 2: File Authorization

Observation:

File download uses
file_id.

Hypothesis:

A user may be able
to download a file
owned by another user
or tenant if ownership
is not validated.

Part 53 — Hypothesis 3: Role Change

Observation:

Organization admins
send role values
through the API.

Hypothesis:

A standard organization member
may be able to call the same
role-change endpoint directly
if server-side role authorization
is missing.

Part 54 — Hypothesis 4: Invitation Binding

Observation:

Invitation acceptance
uses invitation token.

Hypothesis:

An invitation token may
not be correctly bound to
the intended user, tenant
or assigned role.

Part 55 — Hypothesis 5: Revoked Share Link

Observation:

Share links can
be revoked.

Hypothesis:

A previously generated
share link may remain
usable after revocation
if link state is not
validated at access time.

Part 56 — Hypothesis 6: API Key Revocation

Observation:

Users can create
and revoke API keys.

Hypothesis:

A revoked API key may
remain valid if backend
authorization relies on
cached credential state.

Part 57 — Hypothesis 7: Sensitive Property

Observation:

Profile update request
contains multiple JSON
properties.

Hypothesis:

The backend may accept
sensitive properties not
intended to be user-controlled
if property allowlisting
is incomplete.

Part 58 — Hypothesis 8: Tenant Relationship

Observation:

Project requests contain
both org_id
and project_id.

Hypothesis:

The backend may validate
the organization and project
independently without verifying
that the project belongs
to the specified organization.

Part 59 — Hypothesis 9: Removed Member Access

Observation:

Organization members
can be removed.

Hypothesis:

A removed member may retain
access through an existing
session, cached permission
or API token.

Part 60 — Hypothesis 10: Hidden Admin Function

Observation:

JavaScript contains
/admin/export.

Hypothesis:

A standard user may be able
to invoke the administrative
export function directly
if access control exists
only in the frontend.

Part 61 — Create Testing Backlog

Create:

13 Testing_Backlog.csv

Use:

Priority	Hypothesis	Feature	Required Accounts	Status
P1	Cross-user project access	Projects	A + B	Ready
P1	Cross-user file access	Files	A + B	Ready
P1	Cross-tenant project access	Organizations	Tenant A + B	Ready
P1	Role change authorization	Membership	Member + Admin	Ready
P1	Share-link revocation	Sharing	Account A	Ready
P2	Invitation binding	Invitations	A + B	Ready
P2	API key revocation	Developer	Account A	Ready
P2	Sensitive property update	Profile	Account A	Ready

Part 62 — Do Not Test Everything at Once

Prioritize:

High-Impact
Security Boundaries

first.

Recommended order:

1. Object Authorization

2. Tenant Isolation

3. Role Authorization

4. File Access

5. Sharing

6. Authentication State

7. Business Logic

8. Lower-Priority Features

Part 63 — Create Request Ownership Notes

For baseline requests annotate:

Account:
Account A

Tenant:
Tenant A

Object:
Project A

Expected Authorization:
Allowed

This makes later differential testing much easier.

Part 64 — Example Baseline Annotation

Request ID:
REQ-PROJECT-001

Account:
Account A

Role:
Standard User

Object:
Project A

Owner:
Tenant A

Expected:
Allow

Part 65 — Record Negative Space

Also note functionality that does not exist.

Example:

No MFA Feature Observed

No Billing Feature in Training App

No Platform Admin Role Available

Do not invent attack surfaces.

Part 66 — Distinguish Confirmed and Assumed Architecture

Confirmed:

app.novacloud.test
calls
api.novacloud.test

Assumed:

API probably
uses microservices

Keep these separate.

Part 67 — Facts vs Hypotheses

Create two mental categories:

Facts

Hypotheses

Example fact:

POST /api/v2/invitations
contains role parameter.

Hypothesis:

Standard user may be
able to assign admin role.

Never report the hypothesis as though it were already proven.

Part 68 — Map Error Behavior

While using the application normally, record:

401

403

404

Validation Errors

Conflict Errors

These responses help establish expected application behavior.

Part 69 — Authorization Denial Baseline

If an operation is legitimately denied, preserve that request/response.

Example:

Standard User
      ↓
Admin Feature
      ↓
403

This becomes a useful comparison later.

Part 70 — Map API Response Shapes

Document object structures.

Example:

{
  "id": "project-1001",
  "name": "Research Project",
  "organization_id": "org-100",
  "owner_id": "user-101"
}

This reveals important:

Object Relationships

Part 71 — Identify Potential Server-Controlled Fields

From responses you may see:

owner_id

organization_id

role

status

created_by

Later compare whether these appear in editable requests.

Part 72 — Build Client vs Server Map

Example:

Client Controls
├── project_name
├── description
└── file_name

Server Should Control
├── owner_id
├── organization_id
├── role
└── account_status

Part 73 — Map Sharing Trust Boundary

Sharing often creates:

Authenticated
      ↓
Create Link
      ↓
Possession-Based Access

This introduces a new boundary:

Identity-Based Access
      ↓
Token-Based Access

Part 74 — Map Invitation Trust Boundary

Invitation systems transition:

Unknown User
      ↓
Invitation Token
      ↓
Organization Membership

This is a high-value:

Privilege Creation
Boundary

Part 75 — Map API Key Trust Boundary

API key creation transitions:

Authenticated User
      ↓
Longer-Lived Credential
      ↓
API Access

Important future questions include:

Scope

Revocation

Ownership

Permissions

Part 76 — Map File Storage Boundary

Conceptually:

User
      ↓
Application Authorization
      ↓
File Service
      ↓
Storage

Future tests should determine whether:

Storage Access

remains controlled by:

Application Authorization

Part 77 — Identify High-Risk Boundaries

For NovaCloud, the top boundaries are:

User A → User B

Tenant A → Tenant B

Member → Admin

Authenticated App → File Storage

Active Access → Revoked Access

Part 78 — Prioritize by Business Context

Because NovaCloud manages:

Private Files

Projects

Organizations

authorization failures may have higher business relevance than cosmetic frontend issues.

Part 79 — Create Application Mapping Summary

Create:

14 Application_Mapping_Summary.md

Use:

# Application Mapping Summary

## Target

app.novacloud.test

## Supporting API

api.novacloud.test

## Research Accounts

- Account A / Tenant A
- Account B / Tenant B

## Major Application Areas

- authentication
- profile
- organizations
- projects
- files
- sharing
- invitations
- developer/API access

## Primary Objects

- user
- organization
- membership
- project
- file
- invitation
- share link
- API key
- session

## Primary Roles

- guest
- standard user
- organization member
- organization admin

## Highest-Value Security Boundaries

1. User A → User B
2. Tenant A → Tenant B
3. Member → Admin
4. Application → File Storage
5. Active → Revoked Access

## High-Priority Hypotheses

- cross-user project access
- cross-user file access
- cross-tenant project access
- unauthorized role changes
- revoked share-link reuse
- invitation binding weakness
- API key revocation weakness

## Next Phase

Controlled authentication and
authorization testing using
researcher-owned accounts
and objects.

Part 80 — Common Mistake: Testing Before Mapping

Avoid:

Open Application
      ↓
Find ID Parameter
      ↓
Change It

without knowing:

What Object Is This?

Who Owns It?

Which Tenant?

What Should Happen?

Part 81 — Common Mistake: Map Only Pages

A page map is not enough.

You also need:

Objects

Roles

Requests

States

Relationships

Security Decisions

Part 82 — Common Mistake: Assume UI Equals Authorization

Never treat:

Hidden Button

as proof that:

Backend Action
Is Protected

Part 83 — Common Mistake: Ignore Object Relationships

Testing:

project_id

without understanding:

organization_id

may cause you to miss:

Cross-Tenant
Relationship Failures

Part 84 — Common Mistake: Ignore State

A resource may behave differently when:

Active

Revoked

Expired

Removed

Archived

State is part of the attack surface.

Part 85 — Common Mistake: No Baselines

Do not modify requests without preserving:

Known-Good
Behavior

Part 86 — Common Mistake: Use Real Users

Your test model should remain:

Account A
      ↔
Account B

not:

Researcher
      ↓
Unknown Customer

Part 87 — Common Mistake: Overcollect Requests

You do not need every:

Analytics Call

Static Asset

Image Request

Focus on requests that represent:

Security Decisions

Part 88 — Common Mistake: Create Generic Hypotheses

Avoid:

Test authorization.

Prefer:

Account B may be able
to access File A by
changing file_id if
server-side ownership
validation is missing.

Part 89 — Mapping Quality Checklist

Confirm:

Research Accounts Created

User Journey Mapped

Application Areas Mapped

Features Inventoried

Objects Identified

Relationships Identified

Roles Identified

Baseline Requests Saved

API Endpoints Mapped

Security Boundaries Defined

Authorization Matrix Built

Workflow States Mapped

Hypotheses Created

Testing Backlog Created

Part 90 — Lab Success Criteria

You have successfully completed this lab when you can explain:

How NovaCloud Works

Which Objects Exist

Who Owns Them

Which Roles Exist

Which APIs Power Features

Which Security Boundaries Matter

What Authorization
Should Occur

and

Which Security Hypotheses
Should Be Tested Next

Portfolio Deliverables

Keep:

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 Application_Hypotheses.csv

13 Testing_Backlog.csv

14 Application_Mapping_Summary.md

Portfolio Structure

Lab 04 — Web Application Mapping and Security Boundary Analysis
│
├── Application Map
├── User Journey
├── Feature Inventory
├── Research Account Model
├── Role Matrix
├── Object Register
├── Request Register
├── API Feature Map
├── Security Boundary Map
├── Authorization Matrix
├── Workflow State Map
├── Security Hypotheses
├── Testing Backlog
└── Application Mapping Summary

Knowledge Check

1. Why should an application be mapped before deep testing?

2. What is a user journey?

3. What is a feature inventory?

4. What is an application object?

5. Why is object ownership important?

6. What is an object relationship?

7. Why do nested objects matter for authorization?

8. What is a role matrix?

9. Why is a hidden UI control not proof of authorization?

10. Why should proxy traffic be captured during normal usage?

11. What is a baseline request?

12. Why should baseline requests be saved?

13. What is an object identifier?

14. Why should identifiers be documented before being modified?

15. What is an API feature map?

16. What is a session mechanism?

17. What should be mapped in a logout workflow?

18. What should be mapped in a password-reset workflow?

19. What is an invitation workflow?

20. Why are invitation systems security-sensitive?

21. What is a file workflow?

22. What is a share-link workflow?

23. Why are API keys security-sensitive?

24. What is client-controlled data?

25. What is server-controlled data?

26. What is a security boundary?

27. What is horizontal authorization?

28. What is vertical authorization?

29. What is tenant isolation?

30. Why is the browser considered untrusted?

31. What is an authorization matrix?

32. Why should expected authorization behavior be documented?

33. What is an application state?

34. Why are revoked and expired states important?

35. What is a business rule?

36. What is a security assumption?

37. How does a security assumption become a hypothesis?

38. What makes a good authorization hypothesis?

39. Why should facts and hypotheses remain separate?

40. Why should application response structures be documented?

41. What can fields such as owner_id reveal?

42. Why is the file-storage boundary important?

43. What is the invitation trust boundary?

44. What is the API-key trust boundary?

45. What are NovaCloud’s highest-value security boundaries?

46. Why should business context influence prioritization?

47. Why should only security-relevant requests be preserved?

48. Why should researcher-controlled objects be used?

49. What should an application mapping summary contain?

50. What defines successful security boundary analysis?

Key Takeaways

Application security testing should not begin with:

Payload

It should begin with:

Understanding

The professional workflow is:

Use Application
      ↓
Map Journey
      ↓
Map Features
      ↓
Map Roles
      ↓
Map Objects
      ↓
Map Relationships
      ↓
Capture Baselines
      ↓
Map APIs
      ↓
Map States
      ↓
Identify Boundaries
      ↓
Create Hypotheses

Remember:

Page
      ≠
Security Model

Hidden Button
      ≠
Authorization

Object ID
      ≠
Object Ownership

Same Role
      ≠
Same Resource Access

Same Tenant
      ≠
All Resources Allowed

Client Validation
      ≠
Server Validation

A strong researcher should be able to look at:

Project ID

File ID

Organization ID

Role

State

and immediately ask:

Who Controls It?

Who Owns It?

What Relationship
Should Exist?

Which Server-Side
Security Decision
Must Be Enforced?

Career Connection

Web application mapping and security-boundary analysis are critical skills for:

Bug Bounty Hunters

Application Security Engineers

Web Penetration Testers

Product Security Engineers

Security Researchers

Red Teamers

During an interview, you should be able to explain:

Before attempting security
tests, I map the application
from a legitimate user
perspective.

I identify user journeys,
roles, objects, relationships
and workflow states, then map
each important UI action to
its backend API request.

I preserve known-good
baseline requests and document
the expected authorization
decision for each operation.

From that model I identify
horizontal, vertical and
cross-tenant security
boundaries.

I then convert observations,
such as client-controlled
object identifiers or role
parameters, into specific
testable security hypotheses.

This means my testing is
based on the application's
security model rather than
random payloads.

What’s Next?

➡️ Next: Lab 05 — Authentication, Session and Account Security Testing

You now understand:

Users

Roles

Objects

Application Features

HTTP Requests

API Operations

Workflow States

Security Boundaries

The next step is to begin controlled security testing.

We will start with:

Identity

because every later authorization test depends on knowing:

Who the Application
Believes You Are

In the next lab, you will assess:

Registration

Login

Session Creation

Cookies / Tokens

Logout

Password Reset

Account Recovery

Session Revocation

Password Change

Authentication State

using:

Researcher-Controlled Accounts

Baseline Requests

Controlled State Changes

Minimal Validation

You will build:

Authentication Flow Map

Session Register

Token Lifecycle Map

Password Reset Map

Authentication Test Matrix

Validated Findings

Evidence Package

You will move from:

I Understand
the Authentication Flow

to:

I Can Validate
Whether Authentication
and Session Security
Are Correctly Enforced

➡️ Next: Lab 05 — Authentication, Session and Account Security Testing