Lab 05 — Web Application Privilege Escalation

Welcome to Lab 05 — Web Application Privilege Escalation.

In the previous labs, you assessed privilege boundaries at the operating-system level.

Now the same principle moves into the application layer.

Your starting question is:

I AM AUTHENTICATED
AS A NORMAL USER.

CAN I ACCESS DATA,
FUNCTIONS, OR ACTIONS
THAT MY ROLE SHOULD
NOT BE ALLOWED TO USE?

Web application privilege escalation commonly results from failures in:

AUTHENTICATION
      ↓
IDENTITY
      ↓
ROLE
      ↓
OBJECT OWNERSHIP
      ↓
AUTHORIZATION
      ↓
BUSINESS FUNCTION
      ↓
PRIVILEGE BOUNDARY

The objective is not to randomly manipulate requests.

You will systematically determine:

WHO AM I?

WHAT SHOULD I ACCESS?

WHAT CAN I ACTUALLY ACCESS?

WHERE IS AUTHORIZATION ENFORCED?

CAN THE SERVER BE INDUCED
TO PROCESS AN UNAUTHORIZED ACTION?

WHAT IS THE BUSINESS IMPACT?

Perform every activity only against the GoHackersCloud training application, an application you own, intentionally vulnerable lab software, or another application for which you have explicit authorization.

Mission Information

Lab: 05 — Web Application Privilege Escalation
Track: OffSec Labs
Difficulty: Intermediate → Advanced
Estimated Time: 3–5 Hours
Environment: Isolated Web Application Lab
Primary Role: Web Application Penetration Tester
Focus: Authorization and Application Privilege Escalation
Starting Position: Standard Authenticated User
Target: Unauthorized Application Function or Higher-Privilege Role
Deliverable: Web Application Authorization Assessment Report

Mission Scenario

You have been given authorized test accounts for a fictional enterprise application:

NovaPortal

The application contains multiple roles:

Standard User

Team Manager

Support Analyst

Administrator

Your assigned starting account is:

user01

with:

Role:
Standard User

The organization wants to know whether a compromised standard account could access:

Another User's Data

Manager Functions

Support Functions

Administrative Pages

Administrative APIs

Restricted Objects

Sensitive Business Workflows

Your objective is to evaluate the application’s authorization model and identify any privilege paths.

Lab Architecture

                 TESTER
                   |
                   v
              +----------+
              | Browser  |
              | / Proxy  |
              +----------+
                   |
                   v
             +-------------+
             | NovaPortal  |
             |-------------|
             | Web / API   |
             +-------------+
                   |
            +------+------+
            |             |
            v             v
       +---------+   +---------+
       | App/API |   |Database |
       +---------+   +---------+

Application roles:

user01
  ↓
STANDARD USER

manager01
  ↓
MANAGER

admin01
  ↓
ADMINISTRATOR

Learning Objectives

By completing this lab, you should be able to:

• Map application roles
• Establish expected authorization boundaries
• Identify application objects
• Analyze object ownership
• Review horizontal authorization
• Review vertical authorization
• Test administrative functions
• Test API authorization
• Review HTTP methods
• Evaluate workflow authorization
• Analyze session context
• Identify client-side authorization assumptions
• Validate authorization findings safely
• Build privilege paths
• Assess business impact
• Recommend secure authorization controls
• Produce professional evidence

Prerequisites

You should understand:

HTTP

HTTPS

Cookies

Sessions

Authentication

Authorization

REST APIs

JSON

HTTP Methods

Web Proxies

Browser Developer Tools

Basic Application Security

Authentication vs Authorization

Do not confuse these two controls.

Authentication asks:

WHO ARE YOU?

Authorization asks:

WHAT ARE YOU
ALLOWED TO DO?

Conceptually:

LOGIN
  ↓
AUTHENTICATION
  ↓
IDENTITY
  ↓
AUTHORIZATION
  ↓
RESOURCE / FUNCTION

A user may authenticate correctly while the application still contains serious authorization failures.

Horizontal vs Vertical Privilege Escalation

Horizontal

A user reaches another user’s resources.

USER A
   ↓
USER B DATA

Example:

user01

accessing:

user02 profile

without authorization.

Vertical

A lower-privileged user reaches higher-privileged functionality.

STANDARD USER
      ↓
ADMIN FUNCTION

Both are important.

Phase 01 — Confirm Authorization

Record:

Application:

URL:

Authorized Accounts:

Roles:

Testing Window:

Allowed Functions:

Restricted Actions:

Evidence Rules:

Cleanup Requirements:

Example:

Application:
NovaPortal

Environment:
Training Lab

Accounts:
user01
manager01
admin01

Starting Account:
user01

Objective:
Assess authorization boundaries.

Destructive Actions:
Not Permitted

Phase 02 — Create an Evidence Workspace

Create:

Web-Privilege-Lab/
|
+-- 01-Scope/
|
+-- 02-Roles/
|
+-- 03-Endpoints/
|
+-- 04-Objects/
|
+-- 05-Horizontal/
|
+-- 06-Vertical/
|
+-- 07-API/
|
+-- 08-Workflow/
|
+-- 09-Sessions/
|
+-- 10-Evidence/
|
+-- 11-Findings/
|
+-- 12-Report/

For every test record:

Account

Role

Endpoint

Method

Object

Expected Authorization

Observed Authorization

Response

Security Significance

Phase 03 — Establish the Standard User Baseline

Log in as:

user01

Do not test privilege escalation yet.

First understand the legitimate experience.

Document:

Dashboard

Profile

Menu Items

Available Functions

Accessible Records

API Requests

Account Settings

Phase 04 — Record the Identity

Identify how the application represents the logged-in user.

Possible indicators:

Username

User ID

Email

Role

Tenant

Team

Organization

Example:

Username:
user01

User ID:
1001

Role:
USER

Team:
Blue

Phase 05 — Build the Role Matrix

Using the lab accounts, document legitimate access for each role.

Function	User	Manager	Admin
View own profile	Yes	Yes	Yes
Edit own profile	Yes	Yes	Yes
View team members	No	Yes	Yes
Approve request	No	Yes	Yes
User administration	No	No	Yes
System configuration	No	No	Yes

This becomes your:

EXPECTED AUTHORIZATION MODEL

Phase 06 — Map Application Functions

As each authorized lab role, document visible functions.

Example:

/profile

/account

/orders

/team

/reports

/admin

/admin/users

/admin/settings

/api/profile

/api/orders

/api/admin/users

Do not assume hidden endpoints are automatically vulnerable.

The important question is whether the server enforces authorization.

Phase 07 — Capture Representative Requests

Using your browser’s developer tools or an approved web proxy, capture requests for normal user actions.

Record:

URL

HTTP Method

Parameters

Cookies

Headers

Request Body

Response Code

Example:

GET /api/profile/1001

Phase 08 — Identify Application Objects

Common objects include:

Users

Profiles

Orders

Tickets

Documents

Projects

Teams

Reports

Invoices

Requests

Build an object inventory.

Object	Identifier	Owner	Sensitivity
Profile	1001	user01	Medium
Order	ORD-101	user01	Medium
Ticket	TKT-201	user01	Medium
Report	RPT-001	Manager	High

Phase 09 — Understand Object Ownership

A typical authorization rule might be:

USER
  ↓
MAY ACCESS
  ↓
OBJECTS OWNED BY USER

For example:

user01
  ↓
Profile 1001

but not:

user01
  X
Profile 1002

Phase 10 — Test Horizontal Authorization

Suppose the legitimate request is:

GET /api/profile/1001

where:

1001 = user01

In your isolated lab, test whether changing the object identifier to another authorized synthetic test user is rejected.

For example:

GET /api/profile/1002

Expected result:

403 Forbidden

or another appropriate access-denied response.

If the application returns user02’s protected information instead, you may have identified a horizontal authorization flaw.

Phase 11 — Document the Expected Boundary

Before changing identifiers, record:

Current User:
user01

Current Object:
1001

Requested Object:
1002

Object Owner:
user02

Expected:
Denied

Observed:
?

This makes the assessment reproducible.

Phase 12 — Test Read Authorization

Assess whether the current user can read another synthetic user’s:

Profile

Order

Ticket

Document

Record

Use only accounts and objects created for the lab.

Do not collect unnecessary data.

Phase 13 — Test Write Authorization

A read restriction and write restriction may differ.

Conceptually:

CAN I READ IT?

and:

CAN I MODIFY IT?

must be tested separately.

Use harmless synthetic fields when validating modifications.

Phase 14 — Safe Modification Validation

If testing an object-update endpoint, modify only a designated lab field such as:

training_note

or:

display_name

Avoid changing:

Passwords

Email Ownership

Payment Information

Security Settings

Real Business Data

Phase 15 — Horizontal Finding Example

Finding ID:
WEB-PE-001

Title:
Missing Object-Level Authorization on
User Profile Endpoint

Starting Identity:
user01

Affected Endpoint:
GET /api/profile/{id}

Observation:
The endpoint accepts another synthetic
user identifier and returns protected
profile information without validating
ownership.

Impact:
An authenticated user could access
records belonging to other users.

Category:
Horizontal Privilege Escalation

Recommendation:
Perform server-side ownership and
authorization checks for every requested
object.

Phase 16 — Test Vertical Authorization

Now evaluate higher-privileged application functionality.

As:

user01

you should not normally access:

/admin

/admin/users

/admin/settings

Start with direct navigation inside the lab.

Expected:

403

or:

Redirect to an access-denied page

Phase 17 — Hidden Menu Is Not Authorization

Suppose the standard user UI does not show:

Admin

but direct navigation to:

/admin

works.

That means:

UI HIDING
≠
SERVER-SIDE AUTHORIZATION

A secure design requires:

REQUEST
   ↓
SERVER
   ↓
CHECK ROLE / PERMISSION
   ↓
ALLOW OR DENY

Phase 18 — Build a Function Authorization Matrix

Endpoint	User Expected	Manager Expected	Admin Expected	Observed
/profile	Allow	Allow	Allow
/team	Deny	Allow	Allow
/admin/users	Deny	Deny	Allow
/admin/settings	Deny	Deny	Allow

Fill in observed behavior during testing.

Phase 19 — Test Administrative APIs

A protected page may call an API.

For example:

GET /admin/users

may internally call:

GET /api/admin/users

Test authorization at both layers.

Secure architecture requires:

BROWSER PAGE
     ↓
API
     ↓
SERVER AUTHORIZATION

The API must not trust the frontend.

Phase 20 — Compare Roles

Capture the same legitimate function using:

user01

manager01

admin01

Compare:

Endpoint

Method

Parameters

Headers

Response

Role Requirement

This often reveals where the application expects authorization to occur.

Phase 21 — Do Not Trust Client-Side Role Values

Suppose the browser contains:

role=USER

or JavaScript displays:

isAdmin = false

Do not assume modifying a client value should grant privileges.

A secure application should use trusted server-side authorization.

The key question is:

DOES THE SERVER
TRUST CLIENT-CONTROLLED
AUTHORIZATION DATA?

Phase 22 — Review Cookies

Document cookie properties:

Name

Purpose

Secure

HttpOnly

SameSite

Session Identifier

Do not expose complete session tokens in reports.

Redact them:

session=ABCD********XYZ

Phase 23 — Review Session Context

Determine whether the session maps server-side to:

Identity

Role

Organization

Tenant

Permissions

Conceptually:

SESSION TOKEN
     ↓
SERVER SESSION
     ↓
USER
     ↓
ROLE

Phase 24 — Role Changes Should Be Server Controlled

A secure application should not authorize solely from arbitrary request fields such as:

role=admin

Authorization decisions should be based on trusted server-side identity and permission data.

Phase 25 — Test Function-Level Authorization

Identify actions such as:

Create User

Delete User

Approve Request

Generate Report

Change Configuration

Unlock Account

Test whether standard users can directly call the corresponding lab endpoint.

Phase 26 — Safe Function Validation

Do not validate privileged functions by deleting or damaging data.

Prefer harmless operations where possible.

For example:

Request denied?

can often be confirmed without completing the action.

If a state change is required, use designated synthetic records and restore them afterward.

Phase 27 — Test HTTP Methods

An application may secure:

GET

but incorrectly handle:

POST

PUT

PATCH

DELETE

For each important authorized lab endpoint, identify which methods are intended.

Example:

GET /api/users/1001

versus:

PATCH /api/users/1001

Read and modify permissions should be checked independently.

Phase 28 — Create a Method Matrix

Endpoint	GET	POST	PUT/PATCH	DELETE
/api/profile/1001	User	—	Owner	—
/api/users/1002	Admin	Admin	Admin	Admin
/api/orders/101	Owner	—	Owner	—

Then test whether the application actually follows this design.

Phase 29 — Review Parameter-Based Authorization

Applications may accept:

userId

ownerId

accountId

teamId

tenantId

role

Treat these as:

UNTRUSTED INPUT

Server authorization should independently determine whether the current identity can act on the referenced object.

Phase 30 — Test Ownership Validation

Suppose:

POST /api/orders/update

contains:

{
  "orderId": "ORD-101",
  "status": "saved"
}

In the training environment, determine whether the server validates that:

Current User

is authorized to modify:

ORD-101

before processing the request.

Phase 31 — Avoid Blind Parameter Fuzzing

Do not randomly change every parameter.

Use an authorization hypothesis:

I BELIEVE ORDER ID
IS THE SECURITY BOUNDARY.

Then test only that assumption.

Phase 32 — Review Multi-Tenant Authorization

Some applications contain:

Tenant A

Tenant B

A user in one organization should not access another organization’s resources.

Conceptually:

USER
 ↓
TENANT A
 ↓
OBJECT A

must not become:

USER
 ↓
TENANT B
 ↓
OBJECT B

without explicit permission.

Phase 33 — Build Tenant Test Cases

Use synthetic tenant data.

Record:

Current User

Current Tenant

Requested Object

Object Tenant

Expected Result

Observed Result

Phase 34 — Review Team and Department Boundaries

Applications may authorize by:

Team

Department

Project

Region

Business Unit

Do not assume the only boundary is user ownership.

Phase 35 — Review Workflow Authorization

Business workflows may look like:

EMPLOYEE
   ↓
SUBMIT REQUEST
   ↓
MANAGER
   ↓
APPROVE REQUEST
   ↓
FINANCE
   ↓
PROCESS

Ask:

Can a User Skip a Stage?

Can the Submitter Approve
Their Own Request?

Can a Standard User Invoke
a Manager Action Directly?

Phase 36 — Workflow Privilege Escalation

Example:

Standard User
      ↓
Submit Expense
      ↓
Directly Call Approval Function
      ↓
Expense Approved

This is an authorization failure even if no technical exploit is involved.

Phase 37 — Test Workflow State

Use designated synthetic requests.

Document:

Request ID

Current State

Allowed Actor

Allowed Transition

Attempted Actor

Observed Result

Phase 38 — State Transition Matrix

Current State	Action	Allowed Role	Resulting State
Draft	Submit	User	Pending
Pending	Approve	Manager	Approved
Pending	Reject	Manager	Rejected
Approved	Process	Finance	Processed

The server should enforce this model.

Phase 39 — Review Administrative Object Management

Administrator functions may include:

User Management

Role Management

Permission Assignment

Configuration

Audit Access

Application Settings

These deserve the strongest authorization controls.

Phase 40 — Role Assignment Testing

A standard user should not be able to:

Assign Admin Role

Change Own Role

Add Self to Privileged Group

Test this only using synthetic accounts and designated lab endpoints.

Expected:

DENIED

Phase 41 — Never Rely on Disabled Buttons

A UI might show:

[Approve] Disabled

but the underlying API must still reject an unauthorized request.

The server must enforce:

CAN THIS IDENTITY
PERFORM THIS ACTION?

Phase 42 — Review Direct Object References

Object identifiers may be:

Sequential Integer

UUID

Filename

Username

Email

Order Number

A hard-to-guess identifier is not a replacement for authorization.

UUID
≠
ACCESS CONTROL

Phase 43 — Review Download Functions

Test synthetic documents.

Example:

GET /download?id=DOC-1001

Determine whether changing the identifier to another lab user’s document is denied.

Document only minimal content needed to prove access.

Phase 44 — Review Export Functions

Exports can expose larger datasets.

Examples:

CSV Export

PDF Report

Audit Export

User Export

Test whether lower-privilege users can invoke restricted export functions.

Avoid downloading unnecessarily large datasets.

Phase 45 — Review Search APIs

A normal user may have legitimate search access but receive excessive records.

Ask:

Does the API Filter
By User?

Team?

Tenant?

Role?

Phase 46 — Review GraphQL or Unified APIs Conceptually

If the lab uses a query-based API, authorization must still apply to:

Objects

Fields

Actions

Resolvers

Do not assume one authenticated API endpoint means all returned data is authorized.

Phase 47 — Review Administrative Metadata

Even when sensitive operations are blocked, lower-privileged users should not unnecessarily receive:

Internal Role Lists

Administrative User Details

Security Configuration

Hidden Business Data

Excessive metadata may become its own finding.

Phase 48 — Review Error Handling

Compare:

401 Unauthorized

403 Forbidden

404 Not Found

200 OK

Understand what the application reveals.

Authorization should fail securely without exposing unnecessary sensitive information.

Phase 49 — 401 vs 403

A simplified distinction:

401
=
Authentication Required

403
=
Authenticated but
Not Authorized

Applications may intentionally use different patterns, but authorization should remain consistent.

Phase 50 — Review Server-Side Enforcement

The strongest architecture is:

REQUEST
   ↓
AUTHENTICATE
   ↓
IDENTIFY USER
   ↓
LOAD TRUSTED PERMISSIONS
   ↓
IDENTIFY TARGET RESOURCE
   ↓
CHECK AUTHORIZATION
   ↓
PROCESS OR DENY

Phase 51 — Avoid Scattered Authorization

Weak architecture often looks like:

Endpoint A
Checks Role

Endpoint B
Checks Nothing

Endpoint C
Trusts UI

Endpoint D
Checks Ownership Differently

Centralized authorization policies reduce inconsistency.

Phase 52 — Build an Authorization Test Matrix

Test ID	User	Endpoint	Object	Expected	Observed
AUTH-01	user01	/profile/1001	Own	Allow
AUTH-02	user01	/profile/1002	Other	Deny
AUTH-03	user01	/admin/users	Admin	Deny
AUTH-04	manager01	/team	Team	Allow
AUTH-05	user01	/api/approve	Manager	Deny

Phase 53 — Build an Authorization Graph

Example:

user01
   |
   | Authenticated
   v
Standard Role
   |
   | Missing Authorization Check
   v
Admin API
   |
   | Performs
   v
User Management

This is a vertical privilege path.

Phase 54 — Horizontal Privilege Graph

user01
   |
   | Change Object ID
   v
Profile 1002
   |
   | Missing Ownership Check
   v
user02 Data

Phase 55 — Workflow Privilege Graph

user01
   |
   | Own Request
   v
Pending Request
   |
   | Direct Approval Function
   v
Approved

Phase 56 — Prioritize Findings

Consider:

Required Authentication

Required Role

Data Sensitivity

Function Sensitivity

Number of Affected Users

Cross-Tenant Impact

Administrative Capability

Business Process Impact

Phase 57 — Controlled Validation

When a privilege failure is found:

STOP
  ↓
CAPTURE ORIGINAL REQUEST
  ↓
RECORD EXPECTED ACCESS
  ↓
MAKE MINIMAL CHANGE
  ↓
REPLAY IN LAB
  ↓
OBSERVE RESPONSE
  ↓
CAPTURE EVIDENCE
  ↓
RESTORE TEST DATA

Phase 58 — Minimum Proof Principle

You usually do not need to:

Create Administrator Accounts

Delete Users

Download Entire Databases

Change Passwords

Alter Production-Like Configuration

if a less invasive test proves the authorization problem.

Phase 59 — Finding WEB-PE-001

Finding ID:
WEB-PE-001

Title:
Horizontal Authorization Failure on
Profile Endpoint

Starting Role:
Standard User

Affected Endpoint:
GET /api/profile/{id}

Observation:
An authenticated standard user can request
another synthetic user's profile by
changing the object identifier.

Expected:
Access denied.

Observed:
The application returns the protected
record.

Impact:
Authenticated users may gain unauthorized
access to other users' information.

Severity:
High

Root Cause:
Object ownership is not validated
server-side.

Recommendation:
Perform server-side authorization against
the authenticated identity for every
requested object.

Phase 60 — Finding WEB-PE-002

Finding ID:
WEB-PE-002

Title:
Missing Function-Level Authorization on
Administrative Endpoint

Starting Role:
Standard User

Affected Endpoint:
Administrative API

Observation:
The administrative interface is hidden
from standard users, but the underlying
server endpoint does not enforce the
required administrator role.

Impact:
A lower-privileged user could access
administrative application functionality.

Severity:
Critical

Root Cause:
The application relies on frontend
visibility rather than server-side
authorization.

Recommendation:
Require explicit authorization checks on
every privileged server endpoint.

Phase 61 — Finding WEB-PE-003

Finding ID:
WEB-PE-003

Title:
Unauthorized Workflow Approval

Observation:
A standard user can invoke a manager-only
approval operation against a synthetic
request.

Impact:
Users could bypass the intended business
approval process.

Severity:
High

Root Cause:
The server validates workflow state but
does not validate the actor's role.

Recommendation:
Validate both workflow state and the
authenticated user's permission before
every transition.

Phase 62 — Finding WEB-PE-004

Finding ID:
WEB-PE-004

Title:
Cross-Tenant Object Access

Observation:
A user assigned to Tenant A can request
a synthetic object assigned to Tenant B.

Impact:
The weakness could undermine tenant data
isolation.

Severity:
Critical

Root Cause:
Object lookup is performed by identifier
without enforcing tenant membership.

Recommendation:
Bind every object query to the
authenticated tenant and required
permission.

Phase 63 — Finding WEB-PE-005

Finding ID:
WEB-PE-005

Title:
Unauthorized Modification of Another
User's Resource

Observation:
The application prevents unauthorized
reads in one interface but accepts a
write request against an object owned by
another synthetic user.

Impact:
Authenticated users may alter data
outside their authorized scope.

Recommendation:
Apply authorization consistently to
read, create, update, and delete
operations.

Phase 64 — Build the Risk Matrix

Finding	Likelihood	Impact	Severity
Admin function exposure	High	Critical	Critical
Cross-tenant access	High	Critical	Critical
Unauthorized workflow approval	High	High	High
Horizontal profile access	High	High	High
Unauthorized object modification	High	High	High

Adjust according to the actual lab findings.

Phase 65 — Identify Root Causes

Common causes include:

Missing Server-Side Checks

Client-Side Authorization

Inconsistent Endpoint Controls

Missing Object Ownership Validation

Missing Tenant Validation

Weak Role Design

Workflow Logic Errors

Overly Broad API Permissions

Phase 66 — Remediate Object-Level Authorization

The application should perform:

AUTHENTICATED USER
       ↓
TARGET OBJECT
       ↓
OWNERSHIP / RELATIONSHIP
       ↓
REQUESTED ACTION
       ↓
AUTHORIZATION POLICY
       ↓
ALLOW / DENY

Phase 67 — Remediate Function-Level Authorization

Every privileged operation should independently require the correct permission.

Do not rely on:

Hidden Menus

Disabled Buttons

JavaScript Checks

Secret URLs

Phase 68 — Prefer Permissions Over Hard-Coded Roles

Instead of only:

IF ROLE == ADMIN

larger applications may benefit from explicit permissions such as:

USER_READ

USER_MANAGE

REPORT_READ

REQUEST_APPROVE

SYSTEM_CONFIGURE

Then assign permissions according to roles.

Phase 69 — Apply Deny by Default

A strong authorization model follows:

NOT EXPLICITLY ALLOWED
        ↓
DENIED

rather than:

NOT EXPLICITLY DENIED
        ↓
ALLOWED

Phase 70 — Enforce Tenant Boundaries

Queries should include the authenticated context.

Conceptually:

Find object
WHERE

Object ID = Requested ID

AND

Tenant = Authenticated Tenant

AND

User Has Required Permission

Phase 71 — Secure Workflow Authorization

Before a state change:

WHO IS THE USER?

WHAT IS THE ROLE?

WHAT IS THE CURRENT STATE?

IS THE ACTION VALID?

IS THIS USER ALLOWED
TO PERFORM IT?

All must pass.

Phase 72 — Centralize Authorization

Prefer reusable policy enforcement.

Conceptually:

APPLICATION ENDPOINTS
       ↓
AUTHORIZATION LAYER
       ↓
POLICY ENGINE
       ↓
ALLOW / DENY

This reduces inconsistent checks.

Phase 73 — Log Authorization Failures

Security-relevant telemetry may include:

User

Role

Requested Object

Requested Function

Source

Timestamp

Decision

Reason

Avoid logging secrets or sensitive session tokens.

Phase 74 — Detection Opportunities

Monitor patterns such as:

Repeated Access Denials

Sequential Object Requests

Cross-Tenant Requests

Non-Admin Requests to Admin APIs

Unexpected Workflow Actions

High-Volume Object Enumeration

Phase 75 — Build Regression Tests

Every authorization flaw should become a security regression test.

Example:

TEST:

Given:
user01

When:
GET /api/profile/1002

Then:
403 Forbidden

Phase 76 — Test Every Role

Authorization regression testing should include:

Anonymous

Standard User

Manager

Support

Administrator

as applicable.

Phase 77 — Test Every Operation

For each resource test:

CREATE

READ

UPDATE

DELETE

according to business requirements.

This is often called:

CRUD Authorization

Phase 78 — Test Positive and Negative Cases

Positive:

User accesses own profile
→ Allowed

Negative:

User accesses another profile
→ Denied

Both are necessary.

Phase 79 — Cleanup

After completing the lab:

Restore Modified Synthetic Records

Delete Test Objects If Required

Restore Workflow States

Log Out Test Sessions

Remove Temporary Evidence From Target

Secure Captured Requests

Redact Tokens and Secrets

Phase 80 — Retest

After remediation:

ORIGINAL AUTHORIZATION PATH
        ↓
REPLAY SAME REQUEST
        ↓
VERIFY SERVER CHECK
        ↓
CONFIRM DENIAL

Example:

Before:

user01
→ /api/profile/1002
→ 200

After:

user01
→ /api/profile/1002
→ 403

Final Report Structure

Use:

01 Executive Summary

02 Scope

03 Test Accounts

04 Application Architecture

05 Role Matrix

06 Endpoint Inventory

07 Object Inventory

08 Horizontal Authorization

09 Vertical Authorization

10 API Authorization

11 Workflow Authorization

12 Tenant Isolation

13 Session Context

14 Findings

15 Privilege Paths

16 Risk Ratings

17 Remediation

18 Retesting

19 Cleanup

Executive Summary Example

The authorization assessment identified
weaknesses allowing authenticated
lower-privileged users to access
application resources and functions
outside their intended role.

The most significant risks involved
missing object-level authorization,
inconsistent administrative API controls,
and insufficient workflow enforcement.

The primary remediation priority is to
implement centralized server-side
authorization based on authenticated
identity, object ownership, tenant
membership, requested action, and
explicit permissions.

Authorization Finding Template

Finding ID:

Title:

Application:

Starting User:

Starting Role:

Affected Endpoint:

HTTP Method:

Affected Object:

Expected Authorization:

Observed Authorization:

Description:

Privilege Path:

Evidence:

Security Impact:

Likelihood:

Severity:

Root Cause:

Recommendation:

Retest Procedure:

Authorization Test Worksheet

Test ID:

User:

Role:

Tenant:

Endpoint:

Method:

Object:

Object Owner:

Required Permission:

Expected Result:

Observed Result:

Evidence:

Finding ID:

Student Deliverables

Complete:

• Scope record
• Test account inventory
• Role matrix
• Endpoint inventory
• Object inventory
• Ownership matrix
• Horizontal authorization testing
• Vertical authorization testing
• Function authorization testing
• HTTP-method authorization testing
• API authorization testing
• Multi-tenant testing
• Workflow authorization testing
• Session-context assessment
• Privilege-path diagrams
• Findings register
• Risk matrix
• Remediation plan
• Regression test plan
• Cleanup confirmation
• Final assessment report

Web Privilege Escalation Checklist

Scope

• Application authorized
• Test accounts documented
• Roles documented
• Synthetic data identified
• Restricted actions documented

Baseline

• Standard user experience mapped
• Manager experience mapped
• Admin experience mapped
• Expected role matrix created

Application Mapping

• Pages identified
• Endpoints identified
• APIs identified
• Objects identified
• Object ownership identified
• Workflows identified

Horizontal Authorization

• Own objects tested
• Other-user objects tested
• Read authorization tested
• Write authorization tested
• Sensitive downloads tested
• Search filtering reviewed

Vertical Authorization

• Manager functions tested
• Admin pages tested
• Admin APIs tested
• Privileged actions tested
• UI-only restrictions identified

API

• GET authorization reviewed
• POST authorization reviewed
• PUT/PATCH authorization reviewed
• DELETE authorization reviewed
• Object identifiers reviewed
• Server-side enforcement verified

Tenant Boundaries

• Tenant identity documented
• Cross-tenant reads tested
• Cross-tenant modifications tested
• Tenant filtering verified

Workflow

• States mapped
• Allowed transitions mapped
• Actor requirements documented
• Unauthorized transitions tested
• Self-approval scenarios reviewed

Sessions

• Cookies reviewed
• Session identity understood
• Roles mapped server-side
• Sensitive tokens redacted

Validation

• Expected behavior documented
• Minimal request change used
• Synthetic data used
• Evidence captured
• Business impact established
• Cleanup completed

40 Web Application Privilege Escalation Interview Questions

1. What is application privilege escalation?
2. What is authentication?
3. What is authorization?
4. What is horizontal privilege escalation?
5. What is vertical privilege escalation?
6. What is broken access control?
7. What is object-level authorization?
8. What is function-level authorization?
9. Why is hiding an admin menu insufficient?
10. Why must APIs independently enforce authorization?
11. What is object ownership?
12. Why should object identifiers be treated as untrusted input?
13. Does using UUIDs solve authorization problems?
14. What is an IDOR-style authorization issue?
15. Why should read and write authorization be tested separately?
16. What is a role matrix?
17. What is a permission model?
18. What is RBAC?
19. What is ABAC?
20. What does deny-by-default mean?
21. What is multi-tenant isolation?
22. Why must tenant identity be enforced server-side?
23. What is workflow authorization?
24. What is a state transition?
25. Why should the server validate both state and actor?
26. Why should client-side role values not be trusted?
27. What is a session token?
28. Why should session tokens be redacted from reports?
29. What is HTTP 401?
30. What is HTTP 403?
31. Why should different HTTP methods have independent authorization?
32. What is CRUD authorization?
33. What is a business-logic authorization flaw?
34. Why are administrative APIs high risk?
35. Why are export endpoints security-sensitive?
36. Why are negative authorization tests important?
37. What is controlled validation?
38. Why should authorization findings become regression tests?
39. How should authorization failures be logged?
40. How do you confirm an authorization issue has been remediated?

Final Web Application Privilege Escalation Mental Model

Remember:

AUTHENTICATE
    ↓
IDENTIFY USER
    ↓
IDENTIFY ROLE
    ↓
IDENTIFY TENANT
    ↓
IDENTIFY RESOURCE
    ↓
IDENTIFY OWNER
    ↓
IDENTIFY ACTION
    ↓
CHECK PERMISSION
    ↓
ALLOW / DENY

From the penetration tester’s perspective:

STANDARD USER
      ↓
MAP LEGITIMATE ACCESS
      ↓
BUILD ROLE MATRIX
      ↓
IDENTIFY OBJECTS
      ↓
TEST OWNERSHIP BOUNDARIES
      ↓
TEST ROLE BOUNDARIES
      ↓
TEST API BOUNDARIES
      ↓
TEST WORKFLOW BOUNDARIES
      ↓
TEST TENANT BOUNDARIES
      ↓
CORRELATE
      ↓
BUILD PRIVILEGE PATH
      ↓
CONTROLLED VALIDATION
      ↓
ROOT CAUSE
      ↓
REMEDIATION
      ↓
REGRESSION TEST

Do not think only:

Can I Open /admin?

Think:

Can My Current Identity
Cause the Server to Perform
Any Action That Should Require
a Different Identity,
Role, Ownership Relationship,
Tenant, or Permission?

The most important lesson is:

Authentication Tells the Application
Who the User Is.

Authorization Must Decide
What That User Can Do.

A secure application therefore requires:

EVERY REQUEST
      ↓
TRUSTED IDENTITY
      ↓
SERVER-SIDE AUTHORIZATION
      ↓
RESOURCE + ACTION
      ↓
ALLOW OR DENY

What’s Next?

What’s Next?

➡️ You Have Completed the OffSec Labs

Congratulations — you have now completed the practical lab sequence for this learning path.

Your lab progression covered:

Lab 01
Active Directory Attacks
        ↓
Lab 02
Enterprise Pentesting
        ↓
Lab 03
Linux Privilege Escalation
        ↓
Lab 04
Windows Privilege Escalation
        ↓
Lab 05
Web Application Privilege Escalation

These labs were designed to connect the major skills developed throughout your offensive security journey.

You have moved through:

ACTIVE DIRECTORY
       +
ENTERPRISE NETWORKS
       +
LINUX
       +
WINDOWS
       +
WEB APPLICATIONS
       ↓
PRACTICAL PENETRATION
TESTING METHODOLOGY

From Individual Skills to Attack Paths

The most important lesson from these labs is that real enterprise security assessments rarely involve a single isolated vulnerability.

A realistic security problem may look like:

INITIAL ACCESS
      ↓
LOW-PRIVILEGE IDENTITY
      ↓
APPLICATION WEAKNESS
      ↓
SERVER ACCESS
      ↓
PRIVILEGE ESCALATION
      ↓
IDENTITY RELATIONSHIP
      ↓
ACTIVE DIRECTORY
      ↓
ENTERPRISE ATTACK PATH
      ↓
CRITICAL BUSINESS ASSET

Your responsibility as a penetration tester is not simply to demonstrate that individual weaknesses exist.

You should understand:

WHERE THE ATTACK PATH STARTS

WHICH SECURITY BOUNDARIES FAIL

HOW DIFFERENT WEAKNESSES CONNECT

WHICH BUSINESS ASSETS ARE EXPOSED

WHICH CONTROLS SHOULD BREAK THE PATH

Skills You Should Now Be Able to Apply

After completing the lab sequence, you should be comfortable with the methodology behind:

Scoping
   ↓
Reconnaissance
   ↓
Enumeration
   ↓
Attack-Surface Mapping
   ↓
Identity Analysis
   ↓
Authorization Analysis
   ↓
Privilege Escalation
   ↓
Active Directory Assessment
   ↓
Attack-Path Analysis
   ↓
Controlled Validation
   ↓
Evidence Collection
   ↓
Risk Assessment
   ↓
Remediation
   ↓
Retesting

Build Your Pentesting Portfolio

Do not treat the completed labs as exercises that you now forget.

Turn them into professional portfolio material.

Create:

01 — Active Directory Security Assessment

02 — Enterprise Penetration Test

03 — Linux Privilege Escalation Assessment

04 — Windows Privilege Escalation Assessment

05 — Web Application Authorization Assessment

For each project retain sanitized versions of:

Architecture Diagram

Scope

Methodology

Asset Inventory

Attack-Path Diagram

Findings

Risk Matrix

Evidence

Remediation Recommendations

Retest Results

Executive Summary

Never include real credentials, customer information, sensitive screenshots, proprietary data, or material from assessments you are not authorized to publish.

Your Professional Pentesting Workflow

Take this mental model with you:

AUTHORIZE
    ↓
UNDERSTAND
    ↓
ENUMERATE
    ↓
MAP
    ↓
ANALYZE
    ↓
FORM HYPOTHESIS
    ↓
VALIDATE SAFELY
    ↓
CONNECT FINDINGS
    ↓
BUILD ATTACK PATH
    ↓
MEASURE IMPACT
    ↓
COLLECT EVIDENCE
    ↓
REPORT
    ↓
REMEDIATE
    ↓
RETEST

The goal is not:

RUN MORE TOOLS

The goal is:

UNDERSTAND THE ENVIRONMENT
        ↓
UNDERSTAND THE TRUST
        ↓
UNDERSTAND THE WEAKNESS
        ↓
UNDERSTAND THE IMPACT

Final Career Connection

The skills developed throughout this path directly support roles such as:

Penetration Tester

Ethical Hacker

Security Consultant

Red Team Operator

Web Application Penetration Tester

Active Directory Security Specialist

Vulnerability Researcher

Product Security Engineer

Offensive Security Engineer

Continue strengthening the fundamentals while building depth in the area that matches your target role.

Final Readiness Check

Before considering this path complete, make sure you can confidently answer:

Can I scope an authorized assessment?

Can I map an unfamiliar environment?

Can I enumerate without blindly relying on tools?

Can I identify important security boundaries?

Can I analyze identities and permissions?

Can I identify Linux privilege relationships?

Can I identify Windows privilege relationships?

Can I assess Active Directory relationships?

Can I assess web authorization boundaries?

Can I connect individual findings into attack paths?

Can I validate findings without unnecessary impact?

Can I collect useful evidence?

Can I explain business impact?

Can I recommend practical remediation?

Can I retest and prove the attack path is broken?

If the answer is yes, you have moved beyond simply learning individual offensive-security techniques.

You are beginning to think like a professional penetration tester.

Final Mental Model

Remember this throughout your career:

TOOLS
  ↓
TECHNIQUES
  ↓
METHODOLOGY
  ↓
ATTACK PATHS
  ↓
BUSINESS IMPACT
  ↓
REMEDIATION

Tools will change.

Operating systems will change.

Applications will change.

Cloud platforms will change.

Security products will change.

But the fundamental questions remain:

WHAT DO I HAVE?

WHAT CAN I REACH?

WHAT DO I CONTROL?

WHAT TRUSTS ME?

WHAT CAN I INFLUENCE?

WHERE DOES THAT PATH LEAD?

HOW SHOULD THE ORGANIZATION
BREAK THAT PATH?

That mindset is more valuable than memorizing any single command or exploitation technique.

Path Complete

OFFSEC CERTIFICATION ROADMAP
           ↓
OSCP
           ↓
OSWA
           ↓
OSWE
           ↓
OSEP
           ↓
OSED
           ↓
OSEE
           ↓
GOHACKERSCLOUD LABS
           ↓
ACTIVE DIRECTORY
           ↓
ENTERPRISE PENTESTING
           ↓
LINUX PRIVILEGE ESCALATION
           ↓
WINDOWS PRIVILEGE ESCALATION
           ↓
WEB APPLICATION PRIVILEGE ESCALATION
           ↓
PRACTICAL OFFENSIVE SECURITY
CAREER READINESS

You have completed this learning path.

The next step is not another lab.

The next step is to repeat, document, refine, and apply these skills across new authorized environments until the methodology becomes second nature.