Runbook 04 — Web Application Pentest

Modern organizations depend heavily on web applications.

These applications frequently control:

CUSTOMER ACCOUNTS

EMPLOYEE ACCESS

BUSINESS WORKFLOWS

PAYMENTS

DOCUMENTS

REPORTING

ADMINISTRATION

APIs

CLOUD SERVICES

SENSITIVE DATA

A web application penetration test should therefore evaluate much more than individual technical vulnerabilities.

The tester must understand:

WHO USES THE APPLICATION?

WHAT ROLES EXIST?

WHAT DATA EXISTS?

WHAT FUNCTIONS EXIST?

WHERE ARE THE TRUST BOUNDARIES?

HOW IS ACCESS CONTROLLED?

WHAT BUSINESS PROCESSES
DEPEND ON THE APPLICATION?

The purpose of this runbook is to provide a repeatable methodology for conducting an authorized web application penetration test.

Use this runbook only against GoHackersCloud training applications, applications you own, intentionally vulnerable labs, or systems for which you have explicit authorization.

Runbook Information

Runbook: 04 — Web Application Pentest
Track: OffSec
Category: Web Application Security Runbook
Difficulty: Intermediate → Advanced
Primary Role: Web Application Penetration Tester / Security Consultant
Environment: Web Applications and APIs
Primary Goal: Identify application security weaknesses and authorization failures
Primary Deliverable: Web Application Penetration Testing Report

When to Use This Runbook

Use this runbook for:

Web Application Penetration Tests

Authenticated Application Assessments

Customer Portal Assessments

Administrative Portal Assessments

Internal Web Application Tests

API-Backed Application Assessments

Pre-Production Security Reviews

Application Security Validation

Purple Team Exercises

Web Application Pentest Workflow

Use:

AUTHORIZE
    ↓
UNDERSTAND BUSINESS PURPOSE
    ↓
MAP APPLICATION
    ↓
IDENTIFY USERS AND ROLES
    ↓
MAP ENDPOINTS
    ↓
REVIEW AUTHENTICATION
    ↓
REVIEW SESSION MANAGEMENT
    ↓
REVIEW AUTHORIZATION
    ↓
REVIEW INPUT HANDLING
    ↓
REVIEW BUSINESS LOGIC
    ↓
REVIEW APIs
    ↓
REVIEW FILE HANDLING
    ↓
REVIEW SECURITY CONFIGURATION
    ↓
CONTROLLED VALIDATION
    ↓
EVIDENCE
    ↓
BUSINESS IMPACT
    ↓
REMEDIATION
    ↓
RETEST

01 — Confirm Authorization

Before testing, document:

Application Name

Application URL

Environment

Application Owner

Authorized Domains

Authorized APIs

Authorized Accounts

Authorized Roles

Testing Window

Excluded Functions

Restricted Actions

Emergency Contact

Scope Template

Assessment:

Application:

Primary URL:

Additional URLs:

API Base URL:

Environment:

Authorized Accounts:

Authorized Roles:

Authorized Test Data:

Out-of-Scope Functions:

Third-Party Integrations:

Allowed Techniques:

Restricted Techniques:

Testing Window:

Emergency Contact:

02 — Establish Rules of Engagement

Typical allowed activities may include:

Application Mapping

Request Inspection

Authentication Review

Session Review

Authorization Testing

Input Validation Testing

API Testing

Business Logic Assessment

File Upload Assessment

Security Configuration Review

Controlled Vulnerability Validation

Restrict unless explicitly permitted:

Denial of Service

Large Automated Request Volumes

Production Data Modification

Mass Account Creation

Account Lockout Testing

Destructive File Uploads

Real Payment Transactions

Uncontrolled Data Extraction

Third-Party Testing

03 — Define Test Accounts

Ideally obtain several lab identities:

Anonymous

Standard User

User 2

Manager

Support User

Administrator

Example:

Account	Role	Purpose
user01	User	Standard user testing
user02	User	Ownership testing
manager01	Manager	Role comparison
admin01	Administrator	Administrative baseline

04 — Prepare the Workspace

Create:

Web-Pentest/
|
+-- 01-Scope/
|
+-- 02-Mapping/
|
+-- 03-Authentication/
|
+-- 04-Sessions/
|
+-- 05-Authorization/
|
+-- 06-Input-Validation/
|
+-- 07-Business-Logic/
|
+-- 08-API/
|
+-- 09-File-Handling/
|
+-- 10-Configuration/
|
+-- 11-Evidence/
|
+-- 12-Findings/
|
+-- 13-Report/
|
+-- 14-Retest/

Evidence Standard

For every important test record:

Timestamp

Application

User

Role

Endpoint

Method

Request

Expected Result

Observed Result

Evidence

Security Impact

Finding ID

Redact:

Session Tokens

Passwords

API Secrets

Real Customer Data

Personal Information

05 — Understand the Application

Before testing vulnerabilities, understand the application’s purpose.

Ask:

What Does the Application Do?

Who Uses It?

What Data Does It Process?

What Business Workflows Exist?

What Are the Most Sensitive Functions?

Which Systems Does It Integrate With?

06 — Build the Application Architecture

Conceptually map:

USER
 ↓
BROWSER
 ↓
WEB APPLICATION
 ↓
API
 ↓
APPLICATION SERVICES
 ↓
DATABASE
 ↓
EXTERNAL SERVICES

Identify:

Frontend

Backend

API

Database

Identity Provider

Object Storage

Email Services

Payment Services

Third-Party Integrations

07 — Establish Technology Context

Identify technologies where possible:

Web Server

Application Framework

Frontend Framework

API Style

Authentication Mechanism

Session Mechanism

Database Type

Cloud Platform

CDN / WAF

Do not treat technology identification itself as a vulnerability.

08 — Map the Application

Use the application normally.

Document:

Pages

Navigation

Forms

Search

Uploads

Downloads

Profile Functions

Account Functions

Reports

Administrative Functions

API Calls

09 — Create the Endpoint Inventory

Example:

Endpoint	Method	Authentication	Role	Purpose
/login	POST	No	Public	Login
/profile	GET	Yes	User	Profile
/api/orders	GET	Yes	User	Orders
/admin/users	GET	Yes	Admin	User management

10 — Capture Normal Requests

Use:

Browser Developer Tools

Approved Web Proxy

Application Logs

Capture representative legitimate requests.

Understand:

URL

Method

Headers

Cookies

Parameters

Body

Response

Status Code

11 — Identify Input Locations

Inputs may appear in:

Query Parameters

Path Parameters

POST Bodies

JSON

Headers

Cookies

File Uploads

Search Fields

Form Fields

Build an input inventory.

12 — Identify Application Objects

Objects can include:

User

Profile

Order

Invoice

Ticket

Document

Project

Report

Account

Request

Create:

Object	Identifier	Owner	Sensitivity
Profile	1001	user01	Medium
Invoice	INV-100	user01	High
Document	DOC-20	user02	High

13 — Identify Roles and Permissions

Build a role matrix.

Function	User	Manager	Admin
Own profile	Yes	Yes	Yes
Team reports	No	Yes	Yes
User management	No	No	Yes
System settings	No	No	Yes

This becomes your expected access-control baseline.

14 — Authentication Assessment

Authentication answers:

WHO ARE YOU?

Review:

Login

Password Policy

Account Lockout

MFA

Password Reset

Account Recovery

Logout

Remember Me

Federated Login

15 — Review Login Behavior

Document:

Login Endpoint

Request Method

Session Creation

Failure Messages

Lockout Behavior

MFA Flow

Avoid mass password attempts.

16 — Review Authentication Errors

Compare responses for:

Invalid User

Invalid Password

Disabled Account

The application should avoid unnecessary account information disclosure.

17 — Review Password Policy

Assess:

Minimum Length

Complexity Requirements

Reuse

Change Process

Compromised Password Protection

Password security should be evaluated together with:

MFA

Rate Limiting

Risk-Based Authentication

Account Lockout

18 — Review Account Lockout

Determine:

Threshold

Duration

Unlock Process

Administrative Override

Do not intentionally lock accounts unless specifically authorized.

19 — Review MFA

Assess:

Which Roles Require MFA?

Does MFA Protect Admins?

Does Password Reset Affect MFA?

Does Recovery Bypass MFA?

Are Sensitive Functions Reauthenticated?

20 — Review Password Reset

Map:

RESET REQUEST
     ↓
IDENTITY VERIFICATION
     ↓
RESET TOKEN
     ↓
PASSWORD CHANGE
     ↓
SESSION HANDLING

Check whether the process securely binds the reset to the correct user.

21 — Session Management Assessment

After login, determine how sessions are managed.

Review:

Session Cookie

Token Lifetime

Logout

Idle Timeout

Absolute Timeout

Concurrent Sessions

Session Rotation

22 — Review Cookie Security

Check:

Secure

HttpOnly

SameSite

Domain

Path

Expiration

A typical secure session cookie should be protected appropriately for its use.

23 — Redact Session Tokens

Evidence should show:

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

not the complete active token.

24 — Review Session Rotation

Check whether important events rotate or invalidate sessions.

Examples:

Login

Password Change

Privilege Change

MFA Enrollment

Account Recovery

25 — Review Logout

After logout:

Does the Session Stop Working?

Can Old Pages Still Perform Actions?

Are Server-Side Sessions Invalidated?

26 — Review Session Timeout

Evaluate:

Idle Timeout

Absolute Timeout

High-Privilege Session Duration

Administrative sessions often warrant stricter controls.

27 — Authorization Assessment

Authorization asks:

WHAT ARE YOU ALLOWED TO DO?

Review:

Object-Level Authorization

Function-Level Authorization

Role-Based Access

Tenant Boundaries

Workflow Authorization

28 — Horizontal Authorization

Test whether:

USER A

can access:

USER B'S
SYNTHETIC LAB RESOURCE

Example baseline:

GET /api/profile/1001

where:

1001 = user01

Then assess a designated test object belonging to user02.

Expected:

DENIED

29 — Document Ownership Tests

Record:

Current User:

Current Role:

Object:

Object Owner:

Requested Action:

Expected:

Observed:

30 — Vertical Authorization

Test whether:

STANDARD USER

can access:

MANAGER / ADMIN
FUNCTIONS

Examples may include:

/admin

/admin/users

/admin/settings

/api/admin/users

31 — Hidden Functions Are Not Security Controls

This:

ADMIN BUTTON HIDDEN

does not mean:

ADMIN FUNCTION SECURED

Authorization must occur:

REQUEST
 ↓
SERVER
 ↓
CHECK PERMISSION
 ↓
ALLOW / DENY

32 — Review API Authorization Separately

An application page may be protected while its underlying API is not.

Test:

PAGE AUTHORIZATION

and:

API AUTHORIZATION

independently.

33 — Review HTTP Method Authorization

Check expected permissions for:

GET

POST

PUT

PATCH

DELETE

Read access does not automatically imply write access.

34 — Build the Authorization Matrix

User	Endpoint	Method	Object	Expected	Observed
user01	/profile/1001	GET	Own	Allow
user01	/profile/1002	GET	Other	Deny
user01	/admin/users	GET	Admin	Deny

35 — Review Multi-Tenant Isolation

If the application supports:

Tenant A

Tenant B

verify that:

Tenant A User

cannot access:

Tenant B Resource

Use only synthetic test tenants.

36 — Review Object Ownership

Server-side access should consider:

Authenticated User

Tenant

Object

Object Owner

Requested Action

Permission

37 — Input Validation Assessment

Input handling should be reviewed across:

Search

Forms

URLs

JSON

Headers

Uploads

APIs

Your objective is to determine whether untrusted input can alter application behavior beyond what is intended.

38 — Build the Input Matrix

Input	Endpoint	Type	Server Use	Validation
search	/search	Text	Query	Review
id	/profile/{id}	Integer	Object lookup	Review
filename	/upload	File	Storage	Review

39 — Review Input Validation

Assess:

Expected Type

Maximum Length

Allowed Characters

Server-Side Validation

Error Handling

Output Encoding

40 — Injection Risk Assessment

Injection weaknesses can occur when untrusted input is interpreted as:

Database Query

Operating System Command

Directory Query

Template Expression

Application Expression

A secure architecture uses:

Parameterized Queries

Safe APIs

Context-Specific Encoding

Input Validation

Least Privilege

41 — SQL Injection Assessment

In an intentionally vulnerable training application, identify fields that interact with database-backed features such as:

Login

Search

Filters

Reports

Object Lookups

Use minimal validation techniques sufficient to determine whether the application safely separates input from query structure.

Do not dump unnecessary data.

42 — Command Injection Assessment

Potentially risky features include:

Network Diagnostic Tools

File Conversion

Administrative Utilities

Media Processing

Automation Functions

The security question is:

Can User-Controlled Input
Influence an Operating-System
Command Structure?

Controlled lab validation should use harmless actions only.

43 — Cross-Site Scripting Assessment

Review input that is later rendered into:

HTML

JavaScript

DOM

Templates

Consider:

Reflected Input

Stored Input

DOM-Based Processing

The correct remediation depends on output context.

44 — XSS Security Model

A vulnerable relationship may look like:

UNTRUSTED INPUT
      ↓
APPLICATION
      ↓
HTML / SCRIPT CONTEXT
      ↓
BROWSER EXECUTION

Primary defenses include:

Context-Specific Output Encoding

Safe Templating

Input Constraints

Content Security Policy

45 — Review Server-Side Request Functionality

Features that retrieve remote resources may include:

URL Preview

Webhook Validation

Image Import

Document Fetching

Integration Testing

Assess whether server-side requests are constrained to intended destinations.

Keep validation entirely within designated lab systems.

46 — Review File Path Handling

Applications may accept:

Filename

Document ID

Export Path

Template Name

Check whether the application securely maps these values to intended resources.

47 — Business Logic Assessment

Business logic testing asks:

CAN I USE VALID FEATURES
IN AN INVALID SEQUENCE?

Examples:

Skip Approval

Repeat Transaction

Change Restricted State

Apply Benefit Twice

Bypass Required Step

Perform Action as Wrong Role

48 — Map Business Workflows

Example:

CREATE REQUEST
      ↓
SUBMIT
      ↓
MANAGER APPROVAL
      ↓
FINANCE REVIEW
      ↓
COMPLETE

49 — Build the State Matrix

Current State	Action	Allowed Role	Next State
Draft	Submit	User	Pending
Pending	Approve	Manager	Approved
Approved	Process	Finance	Complete

50 — Test Workflow Boundaries

Ask:

Can a Step Be Skipped?

Can a User Approve
Their Own Request?

Can a Completed Transaction
Be Repeated?

Can the Process Be
Executed Out of Order?

Use only synthetic lab records.

51 — Test Quantity and Value Boundaries

Where relevant, assess validation around:

Quantity

Price

Discount

Credit

Limits

Balances

Do not perform real financial transactions.

Use designated training data.

52 — Review Race and Replay Logic Conceptually

Some workflows may rely on:

One-Time Actions

Unique Requests

Idempotency

Single Approval

Evaluate whether repeated legitimate requests could create unintended state.

Keep request volumes low and controlled.

53 — API Assessment

Modern web applications often use APIs extensively.

Map:

REST

GraphQL

Internal APIs

Public APIs

Mobile APIs

54 — Build the API Inventory

Endpoint	Method	Auth	Role	Object
/api/profile	GET	Yes	User	Profile
/api/orders	GET	Yes	User	Orders
/api/admin/users	GET	Yes	Admin	Users

55 — Review API Authentication

Determine whether APIs use:

Session Cookies

Bearer Tokens

API Keys

OAuth

OIDC

Check:

Token Lifetime

Scope

Audience

Expiration

Revocation

56 — Review API Authorization

For every API request ask:

WHO IS CALLING?

WHICH ROLE?

WHICH OBJECT?

WHICH TENANT?

WHICH ACTION?

57 — Review Excessive Data Exposure

A response may contain more data than the interface actually displays.

Compare:

VISIBLE UI DATA

with:

FULL API RESPONSE

Look for unnecessary sensitive fields.

58 — Review Mass Assignment Risk

Applications that accept structured objects should not blindly trust every client-provided field.

Conceptually:

CLIENT OBJECT
    ↓
SERVER
    ↓
ONLY APPROVED FIELDS
SHOULD BE MODIFIABLE

Fields such as:

Role

Privilege

Owner

Tenant

Status

should receive particular scrutiny.

59 — Review API Rate Controls

Assess whether sensitive operations have appropriate limits.

Examples:

Login

Password Reset

OTP Verification

Search

Expensive Reports

Avoid high-volume testing unless specifically authorized.

60 — Review GraphQL Security Conceptually

If GraphQL exists, evaluate:

Authentication

Object Authorization

Field Authorization

Mutation Authorization

Sensitive Metadata Exposure

Complexity Controls

61 — File Upload Assessment

File upload functionality can create significant risk.

Map:

Upload Location

Allowed Types

File Size

Filename Handling

Storage Location

Processing

Download Behavior

62 — Use Harmless Test Files

Use:

Text Files

Benign Images

Synthetic Documents

Do not upload malware or destructive content.

63 — Review File Type Validation

Check whether the application validates:

Extension

Content Type

File Signature

Business Requirement

No single check should be blindly trusted.

64 — Review Filename Handling

Assess whether filenames can affect:

Storage Paths

Existing Files

Downloads

Application Rendering

Servers should generate safe storage identifiers where appropriate.

65 — Review Uploaded File Access

Determine:

Who Can Read the File?

Who Owns It?

Can Another User Access It?

Is It Public?

Is Authorization Enforced?

66 — Review File Download Functions

Map:

DOCUMENT ID
      ↓
SERVER LOOKUP
      ↓
AUTHORIZATION
      ↓
FILE RESPONSE

Do not rely on unpredictable filenames as the only protection.

67 — Security Header Review

Inspect HTTP response headers.

For example:

curl -I https://<LAB_APPLICATION>

Review applicable controls such as:

Content-Security-Policy

Strict-Transport-Security

X-Content-Type-Options

Referrer-Policy

Cache-Control

Recommendations should match application architecture.

68 — Review HTTPS

Assess:

HTTP to HTTPS Redirection

Certificate Validity

Secure Cookies

Mixed Content

Sensitive HTTP Endpoints

69 — Review CORS

Cross-Origin Resource Sharing should allow only required origins and methods.

Map:

Origin

Allowed Origin

Methods

Credentials

Business Requirement

Do not assume permissive CORS alone automatically leads to compromise.

70 — Review Error Handling

Applications should avoid exposing:

Stack Traces

Filesystem Paths

Database Errors

Internal Hostnames

Secrets

Debug Information

71 — Review Debug Features

Look for authorized exposure of:

Debug Mode

Development Pages

API Documentation

Profilers

Diagnostics

The issue is whether sensitive development functionality is exposed where it should not be.

72 — Review Sensitive Information in Client Code

Inspect application-delivered:

JavaScript

Configuration

Source Maps

Frontend Variables

Do not assume every API endpoint or identifier found in JavaScript is confidential.

Focus on actual sensitive data or privileged functionality.

73 — Review Secrets Management

Applications should not expose:

Database Passwords

Private API Keys

Administrative Tokens

Cloud Secrets

Signing Secrets

to browser clients or broadly accessible files.

74 — Review Caching

Sensitive responses should be evaluated for inappropriate browser or intermediary caching.

Examples:

Account Data

Financial Data

Administrative Reports

Personal Information

75 — Review CSRF Protection Where Relevant

For cookie-authenticated state-changing functions, determine whether the application appropriately protects requests from unintended cross-site initiation.

Consider:

SameSite

Anti-CSRF Tokens

Origin Validation

Reauthentication

Architecture matters.

76 — Review Clickjacking Protection

Sensitive interfaces may require framing restrictions.

Consider:

Content-Security-Policy frame-ancestors

or equivalent protections.

77 — Review Sensitive Administrative Functions

Prioritize:

User Creation

Role Assignment

Password Reset

Account Unlock

API Key Management

Configuration

Audit Access

Integration Management

These require strong server-side authorization.

78 — Review Reauthentication

Sensitive actions may require fresh authentication.

Examples:

Password Change

MFA Change

Payment Change

API Key Creation

Administrative Role Change

79 — Review Logging

Application logs should support detection of:

Authentication Failures

Authorization Failures

Administrative Changes

Sensitive Data Access

Workflow Abuse

Configuration Changes

80 — Avoid Sensitive Logging

Applications should avoid logging:

Passwords

Full Session Tokens

Private Keys

Payment Data

Secret Values

81 — Build the Findings Register

Example:

ID	Finding	Area	Severity
WEB-001	Missing object authorization	Access Control	High
WEB-002	Admin API authorization failure	Access Control	Critical
WEB-003	Weak workflow enforcement	Business Logic	High
WEB-004	Sensitive API data exposure	API	Medium
WEB-005	Weak file access control	File Handling	High

82 — Finding WEB-001

Title:
Missing Object-Level Authorization

Starting Role:
Standard User

Observation:
A standard user can access a synthetic
object owned by another test user.

Impact:
Authenticated users may access information
outside their authorized ownership scope.

Root Cause:
The server performs object lookup without
verifying ownership.

Recommendation:
Enforce authorization using authenticated
identity, tenant, object ownership, and
requested action.

83 — Finding WEB-002

Title:
Missing Administrative API Authorization

Observation:
A standard authenticated user can reach
an API operation intended only for
administrators.

Impact:
A lower-privileged application account
could access privileged functionality.

Root Cause:
Authorization is enforced in the user
interface but not consistently on the
server endpoint.

Recommendation:
Apply centralized server-side permission
checks to every administrative operation.

84 — Finding WEB-003

Title:
Business Workflow Authorization Bypass

Observation:
A standard user can trigger a workflow
transition intended for a manager role.

Impact:
The user may bypass required approval
controls.

Recommendation:
Validate both workflow state and actor
permission before every transition.

85 — Finding WEB-004

Title:
Excessive Data Exposure Through API

Observation:
An API response includes sensitive fields
not required by the requesting user or
application interface.

Impact:
Compromise of a standard session could
expose unnecessary information.

Recommendation:
Return only fields required for the
specific operation and role.

86 — Finding WEB-005

Title:
Missing Authorization on Uploaded Files

Observation:
A file uploaded by one synthetic user can
be accessed by another user without the
expected ownership check.

Impact:
Private documents may be exposed across
user boundaries.

Recommendation:
Require server-side authorization for
every file access request.

87 — Build the Attack Path

Do not treat findings independently.

Example:

STANDARD USER
      ↓
OBJECT AUTHORIZATION FAILURE
      ↓
SENSITIVE APPLICATION DATA
      ↓
EXPOSED INTERNAL INFORMATION
      ↓
ADMINISTRATIVE FUNCTION
      ↓
HIGHER BUSINESS IMPACT

88 — Attack Path Worksheet

Attack Path ID:

Starting User:

Starting Role:

Initial Endpoint:

Weakness:

Object:

Intermediate Function:

Required Conditions:

Target Function:

Target Data:

Potential Business Impact:

Evidence:

Recommended Path Break:

89 — Controlled Validation

Use:

HYPOTHESIS
    ↓
EXPECTED BEHAVIOR
    ↓
MINIMUM REQUEST CHANGE
    ↓
OBSERVED BEHAVIOR
    ↓
EVIDENCE
    ↓
STOP

90 — Minimum Proof Principle

Do not:

Delete Real Data

Create Real Admin Accounts

Download Large Data Sets

Modify Real Payments

Disrupt the Application

if a harmless synthetic test sufficiently proves the problem.

91 — Risk Assessment

Consider:

Authentication Required

Required Role

User Interaction

Affected Users

Data Sensitivity

Administrative Capability

Cross-Tenant Impact

Business Process Impact

Ease of Abuse

Existing Controls

92 — Root Cause Analysis

Common causes include:

Missing Server Authorization

Frontend-Only Security

Weak Object Ownership Checks

Weak Tenant Isolation

Unsafe Input Handling

Insecure Workflow Design

Excessive API Responses

Weak File Controls

Insecure Configuration

93 — Authorization Remediation

Use:

DENY BY DEFAULT

SERVER-SIDE CHECKS

CENTRALIZED AUTHORIZATION

OBJECT OWNERSHIP

TENANT VALIDATION

ROLE / PERMISSION CHECKS

94 — Input Handling Remediation

Prefer:

Parameterized Queries

Safe Framework APIs

Context-Specific Output Encoding

Server-Side Validation

Safe File APIs

Least-Privilege Service Accounts

95 — Authentication Remediation

Consider:

MFA

Strong Password Controls

Rate Limiting

Secure Recovery

Session Rotation

Secure Logout

Risk-Based Authentication

96 — API Remediation

Apply:

Strong Authentication

Explicit Authorization

Minimal Responses

Schema Validation

Rate Controls

Secure Error Handling

Central Logging

97 — File Handling Remediation

Apply:

Allowlisted Types

Generated Filenames

Controlled Storage

Authorization

Safe Rendering

Size Limits

Scanning Where Appropriate

98 — Business Logic Remediation

For every sensitive transition verify:

WHO IS ACTING?

WHAT ROLE?

WHAT STATE?

WHAT ACTION?

IS THIS TRANSITION VALID?

IS THIS USER ALLOWED?

99 — Detection Opportunities

Monitor:

Repeated Authorization Failures

Admin API Access by Normal Users

Cross-Tenant Access Attempts

High-Volume Object Requests

Unexpected Workflow Actions

Sensitive File Access

Role Changes

100 — Build Security Regression Tests

Every confirmed finding should become a regression test.

Example:

Given:
user01

When:
GET /api/profile/1002

Then:
403 Forbidden

101 — Positive Authorization Tests

Example:

Given:
user01

When:
GET /api/profile/1001

Then:
200 OK

102 — Negative Authorization Tests

Example:

Given:
user01

When:
GET /api/profile/1002

Then:
Access Denied

Both are important.

103 — Cleanup

At assessment completion:

Restore Synthetic Records

Delete Temporary Test Objects

Remove Uploaded Test Files

Restore Workflow States

Terminate Sessions

Log Out Test Accounts

Remove Temporary Notes

Secure Evidence

104 — Retesting

Use:

ORIGINAL FINDING
      ↓
REPRODUCE BASELINE
      ↓
VERIFY FIX
      ↓
REPEAT ORIGINAL TEST
      ↓
VERIFY DENIAL / SAFE HANDLING
      ↓
CLOSE OR REOPEN

Retest Example

Before:

user01
 ↓
GET /api/profile/1002
 ↓
200 OK

After:

user01
 ↓
GET /api/profile/1002
 ↓
403 Forbidden

105 — Final Report Structure

Use:

01 Executive Summary

02 Scope

03 Rules of Engagement

04 Application Architecture

05 Test Accounts and Roles

06 Application Mapping

07 Authentication

08 Session Management

09 Authorization

10 Input Handling

11 Business Logic

12 API Security

13 File Handling

14 Security Configuration

15 Findings

16 Attack Paths

17 Risk Prioritization

18 Remediation

19 Detection Opportunities

20 Retesting

21 Technical Appendix

Executive Summary Example

The web application penetration test
identified weaknesses across authorization,
business logic, API security, and
application configuration.

The most significant risks involved
inconsistent server-side authorization
and insufficient enforcement of user,
role, object, and workflow boundaries.

Priority remediation should focus on
centralizing server-side authorization,
strengthening object ownership controls,
enforcing workflow permissions, minimizing
API data exposure, and creating regression
tests for all confirmed findings.

Web Application Finding Template

Finding ID:

Title:

Application:

Affected Endpoint:

HTTP Method:

Starting User:

Starting Role:

Affected Object:

Expected Result:

Observed Result:

Description:

Evidence:

Attack Path:

Technical Impact:

Business Impact:

Likelihood:

Severity:

Root Cause:

Recommendation:

Detection Opportunity:

Retest Procedure:

Web Application Test Checklist

Scope

• Application authorized
• URLs documented
• APIs documented
• Accounts documented
• Roles documented
• Test data documented
• Exclusions documented

Mapping

• Pages mapped
• Functions mapped
• Endpoints mapped
• APIs mapped
• Inputs mapped
• Objects mapped
• Workflows mapped
• Roles mapped

Authentication

• Login reviewed
• Error handling reviewed
• Password policy reviewed
• Lockout reviewed
• MFA reviewed
• Recovery reviewed
• Logout reviewed

Session Management

• Cookies reviewed
• Secure flag reviewed
• HttpOnly reviewed
• SameSite reviewed
• Timeout reviewed
• Session rotation reviewed
• Logout invalidation reviewed

Authorization

• Horizontal authorization tested
• Vertical authorization tested
• Object ownership tested
• Role boundaries tested
• HTTP methods tested
• Admin APIs tested
• Tenant isolation tested

Input Handling

• Query parameters reviewed
• Path parameters reviewed
• POST data reviewed
• JSON reviewed
• Headers reviewed
• Output handling reviewed
• Injection risks assessed

Business Logic

• Workflow mapped
• States mapped
• Role transitions reviewed
• Step skipping reviewed
• Duplicate operations reviewed
• Boundary conditions reviewed

API

• Authentication reviewed
• Authorization reviewed
• Object authorization reviewed
• Response data reviewed
• Field modification reviewed
• Rate controls reviewed

Files

• Upload types reviewed
• Filename handling reviewed
• Storage reviewed
• File authorization reviewed
• Download controls reviewed
• Synthetic files used

Configuration

• HTTPS reviewed
• Security headers reviewed
• CORS reviewed
• Errors reviewed
• Debug functionality reviewed
• Sensitive client data reviewed
• Secret exposure reviewed

Validation

• Hypothesis documented
• Expected behavior documented
• Minimum-impact test used
• Synthetic data used
• Evidence captured
• Testing stopped after sufficient proof

Reporting

• Findings reproducible
• Business impact documented
• Root causes documented
• Recommendations actionable
• Detection guidance included
• Retest procedure included

40 Web Application Pentest Review Questions

1. What is web application penetration testing?
2. Why should you understand business purpose before testing?
3. Why is scope important?
4. What is application mapping?
5. What is an endpoint inventory?
6. What is the difference between authentication and authorization?
7. What is MFA?
8. Why should password recovery be tested?
9. What is session management?
10. Why should session tokens be redacted?
11. What does the Secure cookie flag do?
12. What does HttpOnly help protect?
13. What is SameSite?
14. What is horizontal authorization failure?
15. What is vertical authorization failure?
16. What is object-level authorization?
17. Why is hiding an admin button insufficient?
18. Why must APIs enforce authorization independently?
19. What is multi-tenant isolation?
20. Why should object ownership be verified server-side?
21. What is input validation?
22. Why are parameterized database queries important?
23. What is cross-site scripting?
24. Why does output context matter?
25. What is business logic testing?
26. What is workflow authorization?
27. Why should server-side workflow state be validated?
28. What is excessive API data exposure?
29. What is mass assignment?
30. Why are file uploads security-sensitive?
31. Why should uploaded files have authorization controls?
32. What is CORS?
33. What is a Content Security Policy?
34. Why should debug functionality be restricted?
35. Why are hard-coded secrets dangerous?
36. What is controlled validation?
37. What is the minimum proof principle?
38. Why should findings become regression tests?
39. Why should positive and negative authorization tests both exist?
40. How do you prove a web application finding has been remediated?

Final Web Application Pentest Mental Model

Remember:

BUSINESS FUNCTION
      ↓
APPLICATION
      ↓
IDENTITY
      ↓
ROLE
      ↓
SESSION
      ↓
ENDPOINT
      ↓
OBJECT
      ↓
INPUT
      ↓
AUTHORIZATION
      ↓
BUSINESS LOGIC
      ↓
DATA
      ↓
IMPACT

From the tester’s perspective:

UNDERSTAND
    ↓
MAP
    ↓
BASELINE
    ↓
FORM HYPOTHESIS
    ↓
ALTER ONE CONTROLLED VARIABLE
    ↓
OBSERVE SERVER BEHAVIOR
    ↓
VALIDATE
    ↓
CAPTURE EVIDENCE
    ↓
MEASURE BUSINESS IMPACT
    ↓
REMEDIATE
    ↓
RETEST

Do not think:

Which Payload
Should I Try?

Think:

WHAT SECURITY ASSUMPTION
IS THE APPLICATION MAKING?

CAN MY CURRENT USER
VIOLATE THAT ASSUMPTION?

DOES THE SERVER
ENFORCE THE BOUNDARY?

WHAT WOULD FAILURE
MEAN TO THE BUSINESS?

A strong web application penetration tester moves from:

REQUEST

to:

IDENTITY

to:

ROLE

to:

OBJECT

to:

PERMISSION

to:

WORKFLOW

to:

BUSINESS IMPACT

That is the foundation of professional web application penetration testing.

Runbook Track Complete

You have now completed the core OffSec runbook sequence:

RUNBOOK 01
ACTIVE DIRECTORY PENTEST
        ↓
RUNBOOK 02
ENTERPRISE PENTEST
        ↓
RUNBOOK 03
PENETRATION TESTING METHODOLOGY
        ↓
RUNBOOK 04
WEB APPLICATION PENTEST

Together, these runbooks provide a reusable operating model for:

ACTIVE DIRECTORY
       +
WINDOWS / LINUX
       +
NETWORKS
       +
ENTERPRISE INFRASTRUCTURE
       +
WEB APPLICATIONS
       ↓
PROFESSIONAL PENETRATION TESTING

What’s Next?

➡️ OffSec Learning Path Complete

You have completed the certification guidance, practical labs, and professional runbooks for this learning path.

Your next objective is to repeatedly apply the methodology across new authorized training environments until you can move naturally through:

SCOPE
 ↓
DISCOVERY
 ↓
ENUMERATION
 ↓
HYPOTHESIS
 ↓
VALIDATION
 ↓
ATTACK PATH
 ↓
EVIDENCE
 ↓
BUSINESS IMPACT
 ↓
REMEDIATION
 ↓
RETEST

The final goal is not memorizing tools or payloads.

It is developing the ability to enter an unfamiliar authorized environment, understand how it works, identify where security boundaries fail, explain the resulting risk, and show the organization how to fix it.