02 — OSWA

The Offensive Security Web Assessor (OSWA) path focuses on practical web application security assessment.

The goal is not simply to learn a list of web vulnerabilities.

You should develop the ability to look at an unfamiliar authorized application and systematically answer:

How Does This Application Work?

Where Does User Input Enter?

How Does Authentication Work?

How Is Authorization Enforced?

How Is Session State Maintained?

What Trust Boundaries Exist?

Can Application Logic Be Misused?

What Is the Security Impact?

How Should the Weakness Be Fixed?

OSWA is especially relevant if you want to move toward:

Web Penetration Tester

Application Security Analyst

Application Security Engineer

Product Security Analyst

Security Consultant

Web Security Specialist

Perform web security testing only against applications you own, dedicated training environments, or systems where you have explicit authorization.

Certification Information

Certification: OSWA
Primary Domain: Web Application Security
Skill Level: Foundational → Intermediate Practical Web Security
Career Direction: Web Penetration Testing and Application Security
Recommended Approach: Learn web technologies first, then develop a repeatable manual testing methodology

What OSWA Should Build

Your preparation should develop competency in:

Web Architecture

HTTP

Application Mapping

Request Analysis

Response Analysis

Authentication

Authorization

Session Management

Input Validation

Common Web Vulnerabilities

API Security

Application Logic

Manual Testing

Evidence Collection

Reporting

OSWA Career Position

A practical progression is:

WEB FUNDAMENTALS
      ↓
HTTP
      ↓
APPLICATION ARCHITECTURE
      ↓
WEB SECURITY FUNDAMENTALS
      ↓
MANUAL TESTING
      ↓
OSWA
      ↓
WEB PENETRATION TESTING
      ↓
APPLICATION SECURITY
      ↓
ADVANCED WEB SECURITY
      ↓
OSWE

01 — Understand How Web Applications Work

Before learning web vulnerabilities, understand normal application behavior.

A simple model is:

USER
 ↓
BROWSER
 ↓
HTTP REQUEST
 ↓
WEB SERVER
 ↓
APPLICATION
 ↓
DATABASE / API / SERVICE
 ↓
HTTP RESPONSE
 ↓
BROWSER

Every web security assessment begins with understanding this flow.

02 — Understand the Client and Server Model

The browser is generally the client.

The application server makes important security decisions.

Think:

CLIENT-CONTROLLED
      ↓
Request

Parameters

Headers

Cookies

Body

JavaScript Input

versus:

SERVER-CONTROLLED
      ↓
Authentication

Authorization

Validation

Data Access

Business Rules

Security Principle

Never assume:

Because the Browser
Prevents an Action,
the Server Is Secure.

Client-side restrictions are not a replacement for server-side security controls.

03 — Learn HTTP

HTTP is fundamental to web penetration testing.

Understand:

Request

Response

Method

Path

Headers

Body

Status Code

Cookies

Parameters

Basic Request Structure

Conceptually:

METHOD /path HTTP/version

Headers

Body

Common HTTP Methods

Understand:

GET

POST

PUT

PATCH

DELETE

HEAD

OPTIONS

Do not simply memorize methods.

Ask:

What Does This Method Do?

What Resource Does It Affect?

Does It Require Authentication?

Does It Change Data?

Is Authorization Checked?

04 — Understand HTTP Status Codes

Common categories include:

2xx
Success

3xx
Redirection

4xx
Client-Side Request Errors

5xx
Server-Side Errors

Useful examples:

Code	Common Meaning
200	OK
201	Created
301/302	Redirect
400	Bad Request
401	Authentication required/failed
403	Forbidden
404	Not found
500	Server error

Do not assume the status code alone tells the whole story.

Always inspect:

Response Headers

Response Body

Application Behavior

05 — Understand Headers

Important headers may relate to:

Authentication

Content Type

Caching

Origin

Cookies

Security Policy

Proxy Behavior

Your goal is to understand:

WHAT INFORMATION
IS BEING PASSED
BETWEEN CLIENT AND SERVER?

06 — Understand Cookies

Cookies commonly support:

Session Management

Authentication State

User Preferences

Tracking

Review concepts such as:

Cookie Name

Value

Domain

Path

Expiration

Secure

HttpOnly

SameSite

Cookie Security Questions

Ask:

Does the Cookie Represent Authentication?

Is It Protected During Transport?

Can Client-Side Scripts Access It?

When Does It Expire?

Is It Replaced After Login?

Is It Invalidated After Logout?

07 — Understand Sessions

HTTP is fundamentally stateless.

Applications therefore use mechanisms to remember users between requests.

Conceptually:

USER LOGS IN
    ↓
SERVER CREATES SESSION
    ↓
SESSION IDENTIFIER
    ↓
BROWSER
    ↓
FUTURE REQUEST
    ↓
SERVER ASSOCIATES REQUEST
WITH USER

Session Security

Assess:

Session Creation

Session Rotation

Session Expiration

Logout Behavior

Concurrent Sessions

Sensitive Actions

Session Invalidation

08 — Understand Authentication

Authentication answers:

WHO ARE YOU?

Common web authentication mechanisms include:

Username + Password

MFA

Single Sign-On

Federated Authentication

API Tokens

Certificates

Authentication Assessment Questions

Ask:

How Does Login Work?

How Does Registration Work?

How Does Password Reset Work?

How Does MFA Work?

How Does Logout Work?

How Are Failed Attempts Handled?

How Is Account Recovery Protected?

09 — Understand Authorization

Authorization answers:

WHAT ARE YOU ALLOWED TO DO?

Example:

USER A
  ↓
CAN VIEW
OWN PROFILE

ADMIN
  ↓
CAN MANAGE
ALL USERS

Authorization weaknesses occur when server-side access controls do not correctly enforce these boundaries.

Authentication vs Authorization

Authentication
=
Who Are You?

Authorization
=
What Can You Do?

This distinction is one of the most important concepts in web security.

10 — Understand Roles

Applications may contain roles such as:

Guest

User

Manager

Administrator

Support

Auditor

Map each role to:

Accessible Functions

Accessible Data

Allowed Actions

Role Matrix

Role	View Own Data	Edit Own Data	View Others	Admin Functions
Guest	No	No	No	No
User	Yes	Yes	No	No
Admin	Yes	Yes	Yes	Yes

This becomes useful during authorization testing.

11 — Map the Application Before Testing

Do not immediately start entering payloads.

First understand the application.

Map:

Pages

Endpoints

Forms

Parameters

Roles

APIs

Authentication

Uploads

Search

Administrative Functions

Sensitive Data

Application Mapping Workflow

START APPLICATION
      ↓
BROWSE EVERY FUNCTION
      ↓
IDENTIFY REQUESTS
      ↓
IDENTIFY PARAMETERS
      ↓
IDENTIFY ROLES
      ↓
IDENTIFY SENSITIVE ACTIONS
      ↓
CREATE ATTACK-SURFACE MAP

12 — Build an Application Inventory

Create:

Function	Method	Authentication	Role	Sensitive
Login	POST	No	Public	Yes
Profile	GET	Yes	User	Yes
Update Profile	POST	Yes	User	Yes
Admin Panel	GET	Yes	Admin	Yes

13 — Identify Entry Points

User-controlled data may enter through:

URL Parameters

Form Fields

JSON Bodies

HTTP Headers

Cookies

File Uploads

API Requests

Search Boxes

Input Analysis Mental Model

INPUT
  ↓
VALIDATION
  ↓
PROCESSING
  ↓
DATABASE / FILE / COMMAND / TEMPLATE
  ↓
OUTPUT

For every input ask:

Where Does It Go?

How Is It Validated?

How Is It Encoded?

Which Security Boundary Does It Cross?

14 — Learn Proxy-Based Testing

A web assessment often benefits from an intercepting proxy in an authorized lab.

The conceptual flow is:

BROWSER
   ↓
TESTING PROXY
   ↓
WEB APPLICATION

This helps you:

Inspect Requests

Inspect Responses

Modify Parameters

Replay Requests

Compare Behavior

The important skill is understanding the HTTP conversation, not depending on a particular product.

15 — Learn Request Replay

Applications frequently behave differently when:

Parameter Changes

Role Changes

Session Changes

Request Order Changes

Replay allows you to compare:

ORIGINAL REQUEST
        ↓
MODIFIED REQUEST
        ↓
APPLICATION RESPONSE

16 — Learn Authentication Testing

Review:

Login

Logout

Registration

Password Reset

Account Recovery

MFA

Remember-Me Functions

Session Creation

Authentication Testing Mental Model

IDENTITY CLAIM
      ↓
AUTHENTICATION PROCESS
      ↓
SESSION CREATED
      ↓
ACCESS GRANTED

Ask where controls might fail.

17 — Review Account Enumeration

Applications should not unnecessarily reveal whether a specific account exists.

Compare application responses for:

Known Account

Unknown Account

Review differences in:

Message

Response Length

Status

Timing

Workflow

Document only confirmed observable behavior.

18 — Review Password Reset

Password reset is part of the authentication boundary.

Assess:

User Verification

Reset Token Handling

Token Expiration

Token Reuse

Account Binding

Session Behavior After Reset

Security Principle

Strong login security can be undermined by:

Weak Password Recovery

19 — Review MFA Workflow

Where MFA exists, assess:

Enrollment

Challenge

Recovery

Backup Methods

Session Handling

Sensitive Actions

Do not assume:

MFA Enabled
=
Every Authentication Path Protected

20 — Review Logout

Verify whether logout actually ends the authenticated session.

Conceptually test whether:

LOGIN
 ↓
SESSION
 ↓
LOGOUT
 ↓
OLD SESSION

is no longer valid.

21 — Learn Authorization Testing

Authorization testing is often one of the highest-value parts of web assessment.

Evaluate:

Horizontal Access Control

Vertical Access Control

Function-Level Authorization

Object-Level Authorization

Horizontal Authorization

Example:

USER A
 ↓
USER A DATA

should not automatically become:

USER A
 ↓
USER B DATA

Vertical Authorization

Example:

STANDARD USER

should not be able to perform:

ADMINISTRATIVE ACTION

without authorization.

22 — Understand IDOR / Object-Level Access

Applications often reference resources using identifiers.

Conceptually:

USER
  ↓
OBJECT ID
  ↓
SERVER
  ↓
AUTHORIZATION CHECK
  ↓
OBJECT

The security question is:

Does the Server Verify
That This User Is Allowed
to Access This Object?

23 — Test Function-Level Authorization

Do not assume a function is protected simply because:

No Link Appears in the UI

The server must enforce the restriction.

Map:

ROLE
  ↓
ENDPOINT
  ↓
EXPECTED AUTHORIZATION

24 — Learn Input Validation

Applications receive untrusted data.

Secure applications should appropriately validate data based on context.

Examples:

Numbers

Names

Email Addresses

Dates

File Names

URLs

JSON Objects

Validation Questions

Ask:

What Type of Data Is Expected?

What Length Is Expected?

Which Characters Are Expected?

Where Is the Data Used?

Is Validation Server-Side?

25 — Understand Injection

Injection occurs when untrusted input is interpreted as part of a command, query, or other executable context instead of being treated purely as data.

Conceptually:

USER INPUT
    ↓
APPLICATION
    ↓
INTERPRETER / DATABASE / COMMAND

Security depends on keeping:

DATA

separate from:

INSTRUCTIONS

26 — Understand SQL Injection Conceptually

Applications may interact with relational databases.

Normal flow:

USER INPUT
   ↓
APPLICATION
   ↓
DATABASE QUERY
   ↓
DATABASE

A weakness may occur when user input improperly influences query structure.

Focus first on:

Parameterized Queries

Server-Side Validation

Least-Privilege Database Accounts

Error Handling

27 — Understand Cross-Site Scripting

Cross-site scripting relates to unsafe handling of user-controlled content that reaches a browser execution context.

Conceptually:

USER INPUT
     ↓
APPLICATION
     ↓
HTML / JAVASCRIPT CONTEXT
     ↓
ANOTHER USER'S BROWSER

Key defensive concepts include:

Context-Aware Output Encoding

Input Handling

Content Security Policy

Safe Framework Behavior

28 — Understand Stored vs Reflected Behavior

Conceptually:

Reflected
Input → Request → Response

Stored
Input → Storage → Future Response

The difference matters because:

Persistence

Affected Users

Application Context

can differ.

29 — Understand Path Traversal

File-related application functions may use user-controlled paths or file names.

Conceptually:

USER INPUT
  ↓
FILE SELECTION
  ↓
SERVER FILESYSTEM

The security objective is:

User Can Access
Only Intended Files

30 — Understand File Upload Security

File uploads create multiple security concerns.

Assess:

File Type

File Size

File Name

Storage Location

Execution

Access Control

Content Validation

Secure Upload Mental Model

UPLOAD
  ↓
VALIDATE
  ↓
RENAME
  ↓
STORE SAFELY
  ↓
CONTROL ACCESS
  ↓
SERVE SAFELY

31 — Understand Server-Side Request Forgery

Some applications retrieve remote resources on behalf of the user.

Conceptually:

USER
 ↓
URL
 ↓
APPLICATION SERVER
 ↓
REMOTE RESOURCE

The important security question is:

Which Destinations
Is the Server Allowed to Access?

32 — Understand Command Execution Boundaries

Applications may invoke operating-system functionality.

Secure design should prevent user-controlled input from becoming operating-system instructions.

Conceptually:

USER INPUT
     ↓
APPLICATION
     ↓
SYSTEM FUNCTION

Review:

Input Handling

Use of Safe APIs

Application Privilege

Isolation

33 — Understand Template Security

Modern applications may generate dynamic content using templates.

Security problems can occur if user-controlled data improperly influences template processing.

Again, understand the data flow:

USER INPUT
     ↓
TEMPLATE ENGINE
     ↓
OUTPUT

34 — Review Error Handling

Errors may reveal:

Stack Traces

Filesystem Paths

Framework Versions

Database Details

Internal Hostnames

Code Structure

Error Handling Principle

Users should receive enough information to understand the application outcome without exposing unnecessary internal details.

35 — Review Security Headers

Web security assessments may review browser-security controls such as:

Content Security Policy

Transport Security

Framing Restrictions

Content-Type Handling

Referrer Policy

Do not report every missing header as high risk.

Consider:

Application Context

Existing Controls

Actual Exploitability

Business Impact

36 — Review CORS Conceptually

Cross-Origin Resource Sharing controls how browser-based applications interact across origins.

Understand:

ORIGIN A
   ↓
REQUEST
   ↓
ORIGIN B

Then evaluate:

Which Origins Are Trusted?

Which Credentials Are Allowed?

Which Methods Are Permitted?

37 — Learn CSRF Concepts

Applications performing authenticated state-changing actions should consider whether unwanted cross-site requests could trigger sensitive operations.

Conceptually:

AUTHENTICATED USER
      ↓
UNWANTED REQUEST
      ↓
STATE-CHANGING ACTION

Security controls may include:

Anti-CSRF Tokens

SameSite Cookies

Reauthentication

Request Context Validation

38 — Understand Business Logic Vulnerabilities

Not every vulnerability results from malformed technical input.

Applications can be insecure because the workflow itself is flawed.

Examples:

Skipping Required Steps

Repeating One-Time Operations

Changing Transaction Order

Applying Discounts Incorrectly

Performing Actions Without Required Approval

Business Logic Mental Model

EXPECTED WORKFLOW
1 → 2 → 3 → 4

Ask whether the application incorrectly allows:

1 → 4

or:

1 → 2 → 2 → 2

39 — Learn State-Based Testing

Applications change state.

Examples:

Logged Out

Logged In

Email Verified

Payment Pending

Order Approved

Password Reset Requested

Security testing should evaluate whether users can enter invalid states.

40 — Understand API Security

Modern applications commonly rely on APIs.

Common formats include:

REST

JSON

HTTP APIs

API testing requires understanding:

Endpoints

Methods

Parameters

Authentication

Authorization

Objects

Responses

API Architecture

CLIENT
  ↓
API REQUEST
  ↓
API ENDPOINT
  ↓
AUTHENTICATION
  ↓
AUTHORIZATION
  ↓
BUSINESS LOGIC
  ↓
DATABASE / SERVICE

41 — Map API Endpoints

Create:

Endpoint	Method	Auth	Role	Purpose
/api/profile	GET	Yes	User	Read profile
/api/profile	PATCH	Yes	User	Update profile
/api/users	GET	Yes	Admin	User management

42 — Review API Authentication

Determine whether APIs use:

Session Cookies

Bearer Tokens

API Keys

Federated Tokens

Then assess:

Storage

Expiration

Scope

Revocation

Transmission

43 — Review API Authorization

Do not assume authenticated API users can access every object.

Ask:

Does the API Check
Object Ownership?

Does It Check Role?

Does It Check Tenant?

Does It Check Function?

44 — Review Mass Assignment Concepts

Applications may automatically bind user-provided data to internal objects.

Security problems can occur when users can set fields they should not control.

Conceptually:

USER-SUPPLIED JSON
       ↓
APPLICATION OBJECT
       ↓
DATABASE

Ask:

Which Fields
Is the User Allowed to Set?

45 — Review Sensitive Data Exposure

Inspect whether applications expose unnecessary:

Personal Information

Secrets

Tokens

Internal IDs

Financial Information

Administrative Metadata

in:

Responses

JavaScript

Error Messages

Logs

URLs

46 — Review Client-Side JavaScript

JavaScript can reveal:

Endpoints

API Routes

Feature Names

Business Logic

Parameter Names

Client-Side Validation

But remember:

Client-Side Code
Is Visible to Users

Do not place secrets in frontend code.

47 — Review Hidden Functions Carefully

Web applications may contain:

Unused Routes

Legacy Pages

Old APIs

Administrative Functions

Debug Features

Your job is to establish whether those features:

Exist

Are Accessible

Are Authorized

Create Security Impact

48 — Learn Technology Fingerprinting

Identify technologies such as:

Web Server

Framework

Programming Language

CMS

JavaScript Framework

API Technology

This helps guide research.

But avoid assuming:

Technology Identified
=
Vulnerable

49 — Learn Version Research

When a product or framework version is known:

IDENTIFY PRODUCT
      ↓
VERIFY VERSION
      ↓
RESEARCH OFFICIAL ADVISORIES
      ↓
CHECK PRECONDITIONS
      ↓
VALIDATE ENVIRONMENT

50 — Learn Manual Validation

Automated tools may report:

Possible Issue

Your job is to determine:

Is It Real?

Is It Reachable?

Does It Require Authentication?

Which User Is Affected?

What Is the Actual Impact?

51 — Avoid Scanner Dependency

Automated scanning is useful for coverage.

It does not replace understanding.

Bad workflow:

RUN SCANNER
    ↓
EXPORT REPORT
    ↓
FINISHED

Better:

MAP APPLICATION
      ↓
MANUAL TESTING
      ↓
AUTOMATED SUPPORT
      ↓
VALIDATE
      ↓
UNDERSTAND IMPACT
      ↓
REPORT

52 — Build a Repeatable Web Testing Methodology

Use:

01 Confirm Scope

02 Identify Application

03 Map Functionality

04 Map Roles

05 Map Authentication

06 Map Sessions

07 Identify Inputs

08 Test Authorization

09 Test Input Handling

10 Test Business Logic

11 Assess APIs

12 Review Client-Side Components

13 Validate Findings

14 Capture Evidence

15 Cleanup

16 Report

53 — Build an Authentication Checklist

Review:

• Login
• Logout
• Registration
• Password reset
• Account recovery
• MFA
• Session creation
• Session rotation
• Session expiration
• Sensitive action reauthentication

54 — Build an Authorization Checklist

Review:

• Own-object access
• Other-user object access
• Administrative endpoints
• Role changes
• Hidden functions
• API objects
• Direct endpoint access
• Sensitive actions
• Cross-tenant boundaries where applicable

55 — Build an Input Checklist

Review:

URL Parameters

Form Fields

JSON

Headers

Cookies

File Names

Uploaded Files

Search Fields

URLs

IDs

For each record:

Input:

Expected Type:

Validation:

Destination:

Security Boundary:

Observed Result:

56 — Build an API Checklist

Review:

• API endpoints
• HTTP methods
• Authentication
• Authorization
• Object ownership
• Data exposure
• Input handling
• Error handling
• Rate controls where relevant
• Token lifecycle

57 — Use Multiple Test Accounts

Authorization testing often requires:

User A

User B

Administrator

when the lab permits it.

This helps validate:

Horizontal Boundaries

Vertical Boundaries

Keep test identities clearly labeled.

58 — Track Application State

Create a state map.

Example:

Anonymous
   ↓
Registered
   ↓
Authenticated
   ↓
Verified
   ↓
Privileged

Ask:

Which Transition Creates Access?

Which Checks Occur?

Can a User Skip a State?

59 — Capture Evidence Continuously

For every validated issue capture:

Timestamp

Account / Role

Request

Relevant Response

Affected Function

Security Impact

Screenshot Where Useful

Do not unnecessarily capture sensitive customer data.

60 — Evidence Quality

Strong evidence should show:

Expected Behavior

Actual Behavior

Affected User

Affected Resource

Impact

Avoid:

Huge Screenshots

Unrelated Output

Unnecessary Sensitive Data

61 — Learn Finding Validation

Before reporting:

OBSERVE
   ↓
REPEAT
   ↓
VERIFY
   ↓
COMPARE EXPECTED BEHAVIOR
   ↓
CONFIRM SECURITY IMPACT

Do not report:

Interesting Behavior

as:

Confirmed Vulnerability

without validation.

62 — Learn Risk Classification

Consider:

Authentication Required

User Interaction

Privilege Required

Data Sensitivity

Number of Users

Business Function

Exploitability

Existing Controls

Example

Unauthorized Access
to Another User's
Sensitive Financial Data

is generally more significant than:

Minor Information Disclosure
of Non-Sensitive Metadata

63 — Write Professional Findings

Use:

Finding ID:

Title:

Severity:

Affected Component:

Affected Roles:

Description:

Evidence:

Security Impact:

Business Impact:

Recommendation:

Retest Method:

Finding Example — Authorization

Finding ID:
WEB-001

Title:
Insufficient Object-Level Authorization

Severity:
High

Observation:
An authenticated user can access a
resource belonging to another user because
the server does not consistently verify
resource ownership.

Risk:
Users may access information outside their
authorized scope.

Recommendation:
Enforce server-side authorization for every
protected object using the authenticated
user's permitted scope rather than relying
on client-supplied identifiers.

Finding Example — Session Management

Finding ID:
WEB-002

Title:
Session Remains Valid After Logout

Severity:
Medium

Observation:
An authenticated session remains usable
after the user completes the application's
logout workflow.

Risk:
A previously obtained session identifier
may continue providing access even though
the user believes the session has ended.

Recommendation:
Invalidate server-side session state during
logout and verify that previously issued
session identifiers can no longer access
protected resources.

Finding Example — Information Disclosure

Finding ID:
WEB-003

Title:
Detailed Application Errors Expose
Internal Information

Severity:
Low / Medium

Observation:
Application error responses expose internal
implementation details not required by the
user.

Risk:
The information may assist attackers in
understanding application architecture and
planning further attacks.

Recommendation:
Return generic user-facing errors while
recording detailed diagnostic information
in appropriately protected server logs.

64 — Explain Business Impact

Do not stop at:

Authorization Bypass

Explain:

What Data Is Accessible?

Which Users Are Affected?

Can Information Be Changed?

Can Privilege Increase?

Can Business Processes Be Manipulated?

65 — Write Actionable Remediation

Avoid:

Fix Authorization

Prefer:

Perform server-side authorization checks
for every protected request and verify that
the authenticated identity is permitted to
access the requested object before
returning or modifying data.

66 — Retest Findings

After remediation:

ORIGINAL REQUEST
      ↓
ORIGINAL WEAKNESS
      ↓
REPEAT TEST
      ↓
EXPECTED SECURITY CONTROL
      ↓
VERIFY LEGITIMATE FUNCTION

A fix should:

Block Unauthorized Behavior

while preserving:

Authorized Business Function

67 — Build a Web Assessment Report

Recommended structure:

01 Executive Summary

02 Scope

03 Application Overview

04 Assessment Methodology

05 Authentication Review

06 Authorization Review

07 Session Review

08 Input Security

09 API Security

10 Business Logic

11 Technical Findings

12 Remediation

13 Retest Results

68 — Executive Summary

Executives need:

What Was Assessed?

What Were the Most Important Risks?

What Business Functions Were Affected?

What Should Be Fixed First?

Avoid placing:

Raw Requests

Long Payloads

Tool Screenshots

in the executive section.

69 — Build a Vulnerability Matrix

ID	Finding	Severity	Area	Status
WEB-001	Authorization Weakness	High	Access Control	Open
WEB-002	Session Weakness	Medium	Authentication	Open
WEB-003	Error Disclosure	Low	Configuration	Open

70 — Learn Web Assessment Cleanup

Track:

Test Accounts

Uploaded Test Files

Created Records

Temporary Data

Configuration Changes

At completion:

IDENTIFY
  ↓
REMOVE
  ↓
VERIFY
  ↓
DOCUMENT

71 — Build Your Web Lab Strategy

Progress through:

HTTP LABS
   ↓
APPLICATION MAPPING
   ↓
AUTHENTICATION LABS
   ↓
AUTHORIZATION LABS
   ↓
INPUT VALIDATION LABS
   ↓
API LABS
   ↓
BUSINESS LOGIC LABS
   ↓
FULL WEB ASSESSMENTS

72 — Use the Three-Pass Method

Pass 01 — Guided

Understand the concept and workflow.

Pass 02 — Notes Only

Repeat using only your own notes.

Pass 03 — Independent

Perform the assessment from the beginning without a walkthrough.

73 — Maintain a Web Mistake Log

Record:

Mistake:

What I Missed:

Why I Missed It:

Correct Approach:

How I Will Detect It Next Time:

Common examples:

Did Not Map Every Function

Tested Input Before Understanding Workflow

Ignored Authorization

Used Only One Account

Ignored APIs

Did Not Test Logout

Did Not Recheck After Role Change

Relied on Scanner Results

Poor Evidence

74 — Build a Web Testing Knowledge Base

Organize notes into:

HTTP

Authentication

Authorization

Sessions

Input Validation

SQL

Browser Security

Files

Uploads

APIs

Business Logic

Reporting

For each topic document:

How Does It Work?

What Is the Security Boundary?

What Common Weaknesses Exist?

How Do I Validate Safely?

What Evidence Should I Capture?

How Is It Remediated?

75 — Learn Secure Development Concepts

A strong web tester should understand how developers fix issues.

Learn:

Parameterized Queries

Output Encoding

Server-Side Authorization

Secure Session Management

Input Validation

Secure File Handling

Secrets Management

Least Privilege

Secure Error Handling

This dramatically improves your remediation guidance.

76 — Understand Framework Behavior

Modern frameworks often provide built-in security controls.

Learn to distinguish:

Framework Default

Developer Configuration

Custom Application Logic

A weakness may occur because:

Secure Framework Feature
Was Disabled

or:

Custom Logic Bypassed It

77 — Understand Databases

Learn basic relational database concepts:

Tables

Rows

Columns

Queries

Relationships

Users

Privileges

You do not need to become a database administrator, but you should understand how web applications interact with data.

78 — Learn JavaScript Fundamentals

Understand:

Variables

Functions

Objects

Arrays

HTTP Requests

DOM

JSON

This helps when analyzing modern web applications.

79 — Learn JSON

Many applications and APIs exchange JSON.

Example conceptually:

{
  "name": "Alice",
  "role": "user"
}

Understand:

Keys

Values

Objects

Arrays

Types

Then ask:

Which Fields
Should the User
Be Allowed to Control?

80 — Understand REST APIs

REST-style APIs commonly use:

GET

POST

PUT

PATCH

DELETE

against resources.

Example:

/users

/users/123

/orders/456

Security still depends on:

Authentication

Authorization

Input Validation

Business Logic

81 — Understand Multi-Tenant Applications

Some SaaS applications serve multiple organizations.

Conceptually:

TENANT A
   |
   +-- Users
   +-- Data

TENANT B
   |
   +-- Users
   +-- Data

One of the most important boundaries becomes:

Tenant A User
Must Not Access
Tenant B Data

82 — Learn Workflow Analysis

For each important business function ask:

What Must Happen First?

Which Role Performs It?

What Data Changes?

Which Approval Is Required?

Can the Step Be Repeated?

Can the Order Be Changed?

83 — Review Sensitive Actions

Prioritize operations such as:

Password Change

Email Change

Role Change

Payment

Account Deletion

File Sharing

Administrative Changes

These often deserve stronger:

Authorization

Reauthentication

Audit

Confirmation

84 — Learn Rate-Control Concepts

Some application operations may need controls against excessive automated usage.

Examples:

Login

Password Reset

Verification

Search

API Requests

Evaluate:

Business Requirement

Abuse Potential

Existing Protections

User Impact

85 — Understand Logging

Applications should generate useful logs for:

Authentication

Authorization Failures

Administrative Actions

Security Events

Sensitive Changes

Logging vs Monitoring

Logging
=
Record the Event

Monitoring
=
Analyze the Event

86 — Think Like Both Tester and Defender

For each security issue ask:

How Would This Be Prevented?

How Would This Be Detected?

What Logs Would Be Generated?

How Would Incident Response Investigate It?

This makes you a better application-security professional.

87 — OSWA Preparation Strategy

Use four phases.

Phase 01 — Foundation

Learn:

HTTP

Browser Behavior

HTML

JavaScript

APIs

Authentication

Sessions

Phase 02 — Vulnerability Concepts

Learn:

Authorization

Input Security

Browser Security

File Handling

Business Logic

API Security

Phase 03 — Manual Assessment

Practice:

Application Mapping

Request Analysis

Role Comparison

Workflow Testing

Evidence Collection

Phase 04 — Independent Assessment

Perform full authorized web assessments without relying on walkthroughs.

12-Week OSWA Preparation Framework

Weeks 1–2 — Web Fundamentals

Focus on:

HTTP

HTTPS

Requests

Responses

Headers

Cookies

Sessions

Weeks 3–4 — Authentication and Authorization

Focus on:

Login

Logout

Password Reset

Roles

Object Access

Function Access

Weeks 5–6 — Input Security

Focus on:

Validation

Injection Concepts

Browser Output

File Handling

URL Handling

Weeks 7–8 — API Security

Focus on:

REST

JSON

Tokens

Object Access

API Authorization

Input Handling

Weeks 9–10 — Business Logic

Focus on:

Workflow

State

Sensitive Functions

Application Roles

Multi-Step Processes

Week 11 — Full Assessments

Perform complete lab assessments.

Week 12 — Independent Simulation

Practice:

Mapping

Testing

Evidence

Risk Rating

Reporting

Daily Study Model

Example:

30 Minutes
Theory

90 Minutes
Lab

30 Minutes
Notes

30 Minutes
Repeat One Concept

Web Assessment Time Management

Break the assessment into phases:

20%
Application Mapping

20%
Authentication + Session

20%
Authorization

20%
Input + API + Logic Testing

20%
Evidence + Reporting + Recheck

Treat this only as a practice framework.

Real assessments vary by application.

OSWA Readiness Level 01 — HTTP

You understand:

Methods

Headers

Cookies

Sessions

Status Codes

Bodies

Parameters

OSWA Readiness Level 02 — Application Mapping

You can map:

Functions

Roles

Endpoints

Inputs

APIs

Sensitive Workflows

OSWA Readiness Level 03 — Authentication

You can assess:

Login

Logout

Registration

Recovery

Session Lifecycle

MFA Workflow

OSWA Readiness Level 04 — Authorization

You can compare:

User A

User B

Administrator

and determine whether access boundaries are correctly enforced.

OSWA Readiness Level 05 — Input Handling

You understand how untrusted input reaches:

Database

Browser

Filesystem

Server Function

Template

API

and why context matters.

OSWA Readiness Level 06 — API Security

You can assess:

Endpoints

Authentication

Object-Level Authorization

Function-Level Authorization

Input

Sensitive Data

OSWA Readiness Level 07 — Business Logic

You can analyze application workflows rather than simply testing technical payloads.

OSWA Readiness Level 08 — Reporting

You can produce:

Clear Evidence

Reproducible Findings

Security Impact

Business Impact

Actionable Remediation

OSWA Readiness Level 09 — Independent Assessment

You can receive an unfamiliar authorized application and systematically work through:

MAP
 ↓
UNDERSTAND
 ↓
TEST
 ↓
VALIDATE
 ↓
DOCUMENT
 ↓
REPORT

Common OSWA Preparation Mistakes

Avoid:

Learning Payloads Before HTTP

Ignoring Application Logic

Testing Without Mapping the Application

Using Only One User Account

Ignoring Authorization

Ignoring Password Reset

Ignoring Sessions

Ignoring APIs

Depending Entirely on Scanners

Treating Every Missing Header as Critical

Confusing Interesting Behavior with a Vulnerability

Poor Evidence Collection

Ignoring Remediation

Using Walkthroughs Too Quickly

OSWA vs OSCP

OSCP is broader:

NETWORK
+
LINUX
+
WINDOWS
+
WEB
+
ACTIVE DIRECTORY

OSWA focuses more deeply on:

WEB APPLICATIONS
+
HTTP
+
AUTHENTICATION
+
AUTHORIZATION
+
SESSIONS
+
INPUT
+
APIs
+
APPLICATION LOGIC

OSWA vs OSWE

Think:

OSWA
=
Web Application Assessment Foundation

OSWE
=
Advanced Web Application Analysis
+
Source-Code Review
+
Complex Vulnerability Chaining

A strong progression is:

WEB FUNDAMENTALS
      ↓
OSWA
      ↓
REAL WEB TESTING EXPERIENCE
      ↓
PROGRAMMING
      ↓
CODE REVIEW
      ↓
OSWE

Career Connection

OSWA skills support roles such as:

Web Penetration Tester

Application Security Analyst

Application Security Engineer

Product Security Analyst

Security Consultant

Bug Triage Analyst

Secure Development Specialist

Portfolio Project 01 — Authentication Assessment

Build an authorized lab report covering:

Login

Logout

Registration

Password Reset

Session Security

MFA Concepts

Portfolio Project 02 — Authorization Assessment

Demonstrate:

Role Mapping

Object-Level Access

Function-Level Access

Horizontal Authorization

Vertical Authorization

Portfolio Project 03 — API Assessment

Document:

API Architecture

Endpoints

Authentication

Authorization

Input Validation

Sensitive Data

Findings

Portfolio Project 04 — Full Web Assessment

Combine:

APPLICATION MAPPING
      +
AUTHENTICATION
      +
AUTHORIZATION
      +
SESSIONS
      +
INPUT SECURITY
      +
API SECURITY
      +
BUSINESS LOGIC
      +
REPORTING

Interview Question 01

What is the first thing you do during a web application assessment?

Confirm authorization and scope, then understand and map the application before performing deeper security testing.

Interview Question 02

What is the difference between authentication and authorization?

Authentication
=
Who Are You?

Authorization
=
What Are You Allowed to Access or Do?

Interview Question 03

Why are multiple test accounts useful?

They allow you to compare access between different users and roles and evaluate horizontal and vertical authorization boundaries.

Interview Question 04

Why is application mapping important?

Because you cannot reliably assess a web application if you do not understand its functions, roles, inputs, endpoints, and workflows.

Interview Question 05

What is the purpose of session management?

It allows the application to associate multiple HTTP requests with an authenticated or otherwise stateful user context.

40 OSWA Interview and Review Questions

1. What is OSWA?
2. Who should consider OSWA?
3. What is HTTP?
4. What is an HTTP request?
5. What is an HTTP response?
6. What are HTTP methods?
7. What are HTTP headers?
8. What are cookies?
9. What is a session?
10. What is authentication?
11. What is authorization?
12. What is the difference between horizontal and vertical authorization?
13. What is object-level authorization?
14. Why should hidden application functions still be protected server-side?
15. What should be reviewed in password-reset workflows?
16. Why should logout invalidate sessions?
17. What is input validation?
18. What is injection conceptually?
19. What is SQL injection conceptually?
20. What is cross-site scripting conceptually?
21. What is path traversal?
22. Why are file uploads security sensitive?
23. What is SSRF conceptually?
24. What is CSRF conceptually?
25. What is CORS?
26. What is business logic testing?
27. What is application state?
28. What is an API?
29. What is JSON?
30. What is REST?
31. Why must APIs enforce authorization?
32. What is mass assignment conceptually?
33. Why should JavaScript be reviewed?
34. What is technology fingerprinting?
35. Why should scanner findings be validated?
36. Why is evidence important?
37. What should a web security finding contain?
38. Why should business impact be documented?
39. Why is remediation retesting important?
40. What makes someone ready for a web application security role?

OSWA Readiness Checklist

Web Fundamentals

• Understand client/server architecture
• Understand HTTP
• Understand HTTPS
• Understand methods
• Understand headers
• Understand status codes
• Understand cookies
• Understand sessions

Application Mapping

• Map pages
• Map endpoints
• Map parameters
• Map roles
• Map sensitive functions
• Map APIs
• Map application states

Authentication

• Review login
• Review logout
• Review registration
• Review password reset
• Review recovery
• Review MFA workflows
• Review session creation
• Review session invalidation

Authorization

• Test horizontal authorization
• Test vertical authorization
• Review object-level access
• Review function-level access
• Review hidden endpoints
• Review administrative functions
• Review multi-tenant boundaries where applicable

Input Security

• Understand server-side validation
• Understand injection concepts
• Understand output encoding
• Understand file handling
• Understand URL handling
• Understand browser contexts

APIs

• Map API endpoints
• Understand JSON
• Understand authentication
• Review authorization
• Review object ownership
• Review input handling
• Review sensitive data
• Review token lifecycle

Business Logic

• Understand workflows
• Understand application states
• Review sensitive actions
• Review workflow sequence
• Review repeated actions
• Review role transitions

Professional Skills

• Maintain structured notes
• Capture evidence
• Validate findings
• Rate risk
• Explain business impact
• Recommend remediation
• Retest fixes
• Write professional reports

Final OSWA Mental Model

Remember:

AUTHORIZED APPLICATION
        ↓
MAP
        ↓
UNDERSTAND
        ↓
IDENTIFY ROLES
        ↓
IDENTIFY INPUTS
        ↓
ANALYZE AUTHENTICATION
        ↓
ANALYZE SESSIONS
        ↓
ANALYZE AUTHORIZATION
        ↓
ANALYZE INPUT HANDLING
        ↓
ANALYZE APIs
        ↓
ANALYZE BUSINESS LOGIC
        ↓
VALIDATE
        ↓
CAPTURE EVIDENCE
        ↓
ASSESS IMPACT
        ↓
REPORT
        ↓
RETEST

The OSWA mindset is not:

Which Payload
Should I Try?

It is:

How Does This Application
Make Security Decisions,
and Can Those Decisions
Be Broken?

The strongest web security professionals combine:

HTTP KNOWLEDGE
      +
APPLICATION UNDERSTANDING
      +
AUTHENTICATION ANALYSIS
      +
AUTHORIZATION ANALYSIS
      +
INPUT SECURITY
      +
API SECURITY
      +
BUSINESS LOGIC
      +
MANUAL TESTING
      +
REPORTING

What’s Next?

➡️ 03 — OSWE

Next, you will move from web application assessment into advanced application-security analysis.

The next stage will focus on:

Advanced Web Architecture
      ↓
Programming
      ↓
Source-Code Analysis
      ↓
Data-Flow Analysis
      ↓
Authentication Logic
      ↓
Authorization Logic
      ↓
Framework Security
      ↓
Complex Vulnerabilities
      ↓
Vulnerability Chaining
      ↓
Advanced API Analysis
      ↓
Manual Code Review
      ↓
Evidence
      ↓
Professional Reporting

The major shift will be:

OSWA
=
Understand the Application
from the Outside

toward:

OSWE
=
Understand the Application
from the Inside