03 — Web Application Security

Web applications are one of the largest and most important attack surfaces in modern organisations.

Enterprise environments increasingly expose business functionality through:

• Websites
• Customer portals
• Employee portals
• REST APIs
• GraphQL APIs
• Mobile backends
• SaaS applications
• Cloud-native applications
• Microservices
• Administrative portals

A typical application may appear simple from the user’s perspective:

Browser
   ↓
Web Application
   ↓
Database

But the real architecture may be considerably more complex:

User
 ↓
CDN / WAF
 ↓
Load Balancer
 ↓
Frontend
 ↓
API Gateway
 ↓
Application Services
 ├──────────────┐
 ↓              ↓
Database       Cache
 ↓
Object Storage
 ↓
External Services

Every component introduces:

• Inputs

• Identities

• Trust relationships

• Authorization decisions

• Data flows

• Security boundaries

The Ethical Hacker’s objective is to understand those relationships and determine where security assumptions can be broken.

Module Mission

Your mission is to develop a repeatable methodology for assessing authorised web applications and APIs.

The core workflow is:

Scope
  ↓
Application Discovery
  ↓
Architecture Understanding
  ↓
Technology Fingerprinting
  ↓
Content Enumeration
  ↓
Authentication Analysis
  ↓
Session Analysis
  ↓
Authorization Testing
  ↓
Input Mapping
  ↓
Vulnerability Testing
  ↓
Business Logic Analysis
  ↓
API Assessment
  ↓
Attack Path Development
  ↓
Impact Validation
  ↓
Evidence
  ↓
Reporting

By the end of this module, you should be able to approach an unfamiliar application and systematically answer:

What does this application do?

Which technologies does it use?

Where does data enter?

How are users authenticated?

How is authorization enforced?

Which trust boundaries exist?

Which sensitive operations are available?

Can application weaknesses be chained?

What would successful exploitation mean to the business?

1. What Is Web Application Security Testing?

Web Application Security Testing evaluates whether an application securely handles:

Users

Authentication

Authorization

Sessions

Inputs

Data

Files

APIs

Business Processes

Backend Services

The objective is not simply to run a vulnerability scanner.

A professional assessment attempts to understand how the application actually works.

2. Why Web Applications Are Attractive Targets

Web applications frequently sit between:

Internet
   ↓
Application
   ↓
Business Systems
   ↓
Sensitive Data

A vulnerability may therefore provide access to:

• Customer information

• Employee information

• Financial records

• Business workflows

• Internal services

• Cloud resources

• Administrative functionality

Applications can become gateways into larger enterprise environments.

3. Understand the Application Architecture

Before testing, identify the major components.

Example:

Browser
   ↓
Frontend
   ↓
Backend API
   ↓
Application Server
   ↓
Database

A modern architecture may include:

Internet
   ↓
CDN
   ↓
WAF
   ↓
Load Balancer
   ↓
Frontend
   ↓
API Gateway
   ↓
Microservices
   ↓
Database
   ↓
Cloud Services

Each transition represents a potential trust boundary.

4. Map Trust Boundaries

Ask:

Where does untrusted data become trusted?

Example:

Internet User
     ↓
Web Application
     ↓
Backend API
     ↓
Database

Potential boundaries include:

User → Application

Application → API

API → Database

Application → Cloud

Application → Third Party

Security controls should exist around these boundaries.

5. Understand HTTP

HTTP is the foundation of web communication.

A simplified transaction:

Client
   ↓
HTTP Request
   ↓
Server
   ↓
HTTP Response
   ↓
Client

Understanding HTTP is one of the most important web penetration testing skills.

6. HTTP Request Structure

A simplified request:

GET /account HTTP/1.1
Host: app.example.lab
User-Agent: Browser
Cookie: session=example

Important components include:

Method

Path

Headers

Cookies

Parameters

Body

Each can influence application behaviour.

7. HTTP Response Structure

Example:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=example

<html>
...
</html>

Responses may reveal:

• Application behaviour

• Authentication state

• Error information

• Technologies

• Security controls

8. HTTP Methods

Common methods include:

GET

POST

PUT

PATCH

DELETE

HEAD

OPTIONS

Do not assume application security is identical across methods.

For example:

GET /users/100

and:

DELETE /users/100

have very different security implications.

9. HTTP Status Codes

Important categories include:

2xx → Success

3xx → Redirect

4xx → Client Error

5xx → Server Error

Common examples:

Code	Meaning
200	OK
201	Created
301	Permanent Redirect
302	Redirect
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
500	Internal Server Error

Status codes help you understand application behaviour.

10. HTTP Headers

Important headers may include:

Host

Authorization

Cookie

Set-Cookie

Content-Type

Origin

Referer

Location

User-Agent

Security-related response headers may also reveal protection mechanisms.

11. Cookies

Applications commonly use cookies to maintain state.

Example:

Cookie: session=abc123

Cookies may contain:

• Session identifiers

• Preferences

• Authentication information

• Tracking identifiers

Treat authentication-related cookies as sensitive.

12. HTTPS

HTTPS protects HTTP communication using TLS.

Conceptually:

Browser
   ↓
Encrypted Connection
   ↓
Web Server

HTTPS helps protect against interception.

It does not automatically make the application secure.

An HTTPS application can still contain:

• SQL injection

• Broken access control

• XSS

• Business logic flaws

• Authentication weaknesses

13. Your Web Testing Environment

A typical authorised lab may contain:

Ethical Hacker Workstation
        ↓
Browser
        ↓
Intercepting Proxy
        ↓
Vulnerable Web Application

This allows you to observe and modify requests inside your controlled environment.

14. Intercepting Proxies

An intercepting proxy sits between the browser and application.

Browser
   ↓
Proxy
   ↓
Application

It allows you to inspect:

Requests

Responses

Cookies

Parameters

Headers

API Calls

Understanding requests manually is essential.

15. Burp Suite

Burp Suite is commonly used for authorised web application security testing.

Important capabilities include:

• Proxy

• HTTP history

• Repeater

• Decoder

• Comparer

The tool is useful because it allows you to understand and manipulate HTTP communication.

The skill is not clicking buttons.

The skill is interpreting application behaviour.

16. Configure Your Lab Proxy

A typical lab workflow is:

Browser
   ↓
127.0.0.1:8080
   ↓
Intercepting Proxy
   ↓
Lab Application

Confirm that only authorised application traffic is being tested.

17. Establish the Application Scope

Before testing, document:

Primary Domain

Subdomains

Applications

APIs

Authentication Portals

Administrative Interfaces

Excluded Services

Third-Party Integrations

A web application’s visible frontend may represent only part of the attack surface.

18. Application Mapping

Browse the application normally before attacking anything.

Understand:

• Pages

• Features

• User roles

• Authentication

• Workflows

• Forms

• File uploads

• Search

• Account settings

• APIs

• Administrative functions

Build an application map.

19. Example Application Map

Application
│
├── /
├── /login
├── /register
├── /account
├── /orders
├── /search
├── /upload
├── /api
└── /admin

Then determine which paths require which privileges.

20. Content Discovery

Applications may contain endpoints not linked from the visible interface.

Examples:

/admin

/backup

/api

/debug

/test

/uploads

Content discovery should remain within authorised scope.

The objective is attack-surface discovery.

21. Technology Fingerprinting

Identify:

Web Server

Programming Language

Framework

CMS

JavaScript Framework

API Technology

Authentication Technology

Cloud Services

Possible clues include:

• HTTP headers

• Cookies

• HTML

• JavaScript

• Error messages

• File extensions

Technology identification guides deeper testing.

22. Avoid Blind Fingerprinting

A response header might claim:

Server: nginx

Treat this as evidence, not absolute truth.

Headers can be modified.

Use multiple observations where possible.

23. JavaScript as an Information Source

Modern applications often place significant functionality in JavaScript.

Reviewing client-side code may reveal:

API Endpoints

Parameter Names

Application Routes

Feature Flags

Hidden Functionality

Third-Party Services

Do not assume functionality is secure merely because it is hidden from the user interface.

24. Client-Side Security Is Not Authorization

Suppose an administrator button is hidden using JavaScript.

if (role != "admin") {
    hideAdminButton();
}

This does not securely prevent access.

Real authorization must be enforced server-side.

25. Input Mapping

One of the most important tasks is identifying every place where users control data.

Potential inputs include:

URL Parameters

POST Bodies

JSON

Cookies

Headers

File Uploads

API Parameters

Path Values

Build an input map.

26. Example Input Map

Endpoint	Method	Parameter	Purpose
/login	POST	username	Authentication
/login	POST	password	Authentication
/search	GET	q	Search
/account	GET	id	Account selection
/upload	POST	file	Document upload

Each input becomes a testing point.

27. Authentication

Authentication answers:

Who are you?

Common authentication mechanisms include:

Username + Password

MFA

SSO

OAuth

OIDC

SAML

API Keys

Tokens

Authentication testing should examine the complete lifecycle.

28. Authentication Workflow

Map:

Login
  ↓
Credential Validation
  ↓
MFA
  ↓
Session Creation
  ↓
Authenticated Application

Ask where the workflow could fail.

29. Authentication Testing Questions

Consider:

• Is MFA enforced?

• Are passwords protected?

• Are default credentials present?

• Is account enumeration possible?

• Is rate limiting present?

• Are password resets secure?

• Are sessions invalidated correctly?

• Are administrative accounts better protected?

Do not perform uncontrolled password attacks.

30. Account Enumeration

Applications may reveal whether an account exists.

Weak behaviour:

Username does not exist

versus:

Password incorrect

This difference may allow an attacker to identify valid usernames.

A safer application often uses consistent responses.

31. Password Reset Security

Password reset functionality is part of the authentication boundary.

Assess:

Identity Verification

Reset Token

Token Expiration

Token Reuse

Account Binding

Session Handling

A secure login can be undermined by a weak recovery process.

32. Multi-Factor Authentication

MFA should be reviewed as a workflow.

Ask:

Can MFA Be Bypassed?

Is It Required for Every Login Path?

Is It Required for Sensitive Actions?

Are Recovery Mechanisms Secure?

Do not simply confirm that an MFA page exists.

33. Session Management

After authentication, the application needs to remember the user.

Conceptually:

User Login
    ↓
Session Created
    ↓
Session Identifier
    ↓
Future Requests

The session identifier may effectively become a temporary credential.

34. Session Security

Review:

• Randomness

• Expiration

• Rotation

• Logout

• Concurrent sessions

• Cookie attributes

• Privilege changes

If a session identifier is compromised, an attacker may be able to impersonate the user.

35. Cookie Security Attributes

Important cookie attributes include:

Secure

HttpOnly

SameSite

Their presence and configuration can reduce certain attack scenarios.

Evaluate them within the application’s architecture.

36. Session Fixation

Session fixation occurs when an application improperly allows an attacker-known session identifier to remain valid after authentication.

Secure applications should generally rotate relevant session identifiers when authentication state changes.

37. Session Termination

Test whether:

Logout
   ↓
Session Invalidated

A logout button that only redirects the browser but leaves the server-side session valid may create unnecessary risk.

38. Authorization

Authentication asks:

Who are you?

Authorization asks:

What are you allowed to do?

Broken authorization is one of the most important application security categories.

39. Horizontal Authorization

Horizontal authorization controls access between users at similar privilege levels.

Example:

Alice
 ↓
/account/1001

The application should not allow Alice to access:

/account/1002

if that account belongs to Bob.

40. Vertical Authorization

Vertical authorization controls access between privilege levels.

Example:

Normal User
     X
/admin

A normal user should not gain administrator functionality merely by directly requesting an administrator endpoint.

41. IDOR / Object-Level Authorization

Consider:

GET /api/orders/1001

If changing:

1001

to:

1002

returns another user’s order without authorization, the application may have an object-level access control weakness.

The issue is not predictable IDs.

The issue is missing authorization.

42. Build an Authorization Matrix

Use:

Function	Anonymous	User	Manager	Admin
View Profile	No	Yes	Yes	Yes
View Other Users	No	No	Limited	Yes
Create User	No	No	No	Yes
Delete User	No	No	No	Yes

Then validate actual behaviour.

43. Authorization Must Be Tested Server-Side

Do not rely on:

• Hidden buttons

• Disabled fields

• JavaScript

• URL obscurity

Send requests directly and observe server behaviour.

44. Input Validation

Applications receive untrusted data.

Secure architecture should conceptually follow:

Untrusted Input
      ↓
Validation
      ↓
Safe Processing
      ↓
Output

When untrusted data reaches sensitive interpreters, vulnerabilities may occur.

45. Injection

Injection occurs when attacker-controlled input influences commands or queries interpreted by another component.

Conceptually:

User Input
    ↓
Application
    ↓
Interpreter
    ↓
Unexpected Behaviour

Examples include:

• SQL injection

• Command injection

• LDAP injection

• Template injection

46. SQL Injection

Consider insecure conceptual logic:

SELECT * FROM users
WHERE username = '<user input>';

If user input is concatenated directly into the query, it may alter query logic.

The root problem is unsafe query construction.

47. SQL Injection Impact

Depending on application permissions and database architecture, SQL injection may affect:

Authentication

Data Confidentiality

Data Integrity

Application Availability

In some environments, it may also contribute to broader compromise.

Impact must be validated carefully.

48. SQL Injection Testing Methodology

Use a structured process:

Identify Input
     ↓
Establish Normal Response
     ↓
Introduce Controlled Variation
     ↓
Observe Difference
     ↓
Form Hypothesis
     ↓
Validate Safely

Do not begin by dumping databases.

Prove the vulnerability with the minimum necessary impact.

49. SQL Injection Remediation

Primary controls typically include:

• Parameterized queries

• Prepared statements

• Safe ORM usage

• Input validation

• Least-privileged database identities

The strongest remediation addresses the unsafe query construction itself.

50. Command Injection

Command injection can occur when user-controlled input reaches an operating system command interpreter.

Conceptually:

User Input
    ↓
Application
    ↓
Shell Command
    ↓
Operating System

This can become a critical trust-boundary failure.

51. Command Injection Impact

Potential consequences include:

Application Compromise
       ↓
Operating System Access
       ↓
Credential Exposure
       ↓
Internal Network Access

This demonstrates how a web vulnerability may become an enterprise attack path.

52. Cross-Site Scripting

Cross-Site Scripting occurs when attacker-controlled content is executed in another user’s browser within the application’s security context.

Conceptually:

Attacker Input
      ↓
Application
      ↓
Victim Browser
      ↓
Script Execution

53. Reflected XSS

Conceptually:

Malicious Input
      ↓
Request
      ↓
Application Response
      ↓
Browser Execution

The malicious content is reflected through the application’s response.

54. Stored XSS

Stored XSS persists attacker-controlled content.

Example:

Attacker Comment
      ↓
Database
      ↓
Application
      ↓
Victim Browser

Stored XSS may affect multiple users.

55. DOM-Based XSS

DOM-based XSS occurs when insecure client-side JavaScript processes attacker-controlled data and places it into dangerous browser contexts.

The vulnerable behaviour may exist largely within the browser rather than the server response.

56. XSS Impact

Depending on application context, XSS may enable:

• User impersonation

• Sensitive action execution

• Interface manipulation

• Information exposure

• Phishing within a trusted origin

Impact depends heavily on the application’s functionality and browser protections.

57. Cross-Site Request Forgery

CSRF attempts to cause an authenticated user’s browser to perform an unintended action.

Conceptually:

Victim Authenticated
      ↓
Malicious Request Triggered
      ↓
Target Application
      ↓
Action Performed

Applications should protect sensitive state-changing operations appropriately.

58. CSRF and Modern Applications

CSRF risk depends on factors such as:

• Cookie authentication

• SameSite behaviour

• Request methods

• CSRF tokens

• Origin validation

Do not automatically report CSRF based on the absence of one particular control.

Understand the complete workflow.

59. Server-Side Request Forgery

SSRF occurs when an attacker can influence a server to make requests.

Conceptually:

Attacker
   ↓
Application
   ↓
Server-Side Request
   ↓
Internal / External Resource

This is particularly important in cloud environments.

60. SSRF Attack Path

A possible cloud scenario:

Web Application
      ↓
SSRF
      ↓
Internal Service
      ↓
Cloud Metadata / API
      ↓
Workload Identity
      ↓
Cloud Resources

Modern cloud protections can alter this path, so assess the actual environment.

61. Path Traversal

Applications may accept file paths.

If input is not handled securely, users may access files outside the intended directory.

Conceptually:

Requested File
      ↓
Application
      ↓
File System

The security requirement is to constrain access to authorised resources.

62. File Inclusion

Some application architectures dynamically include files or templates.

Unsafe user control over those paths can create security weaknesses.

Assess:

• How paths are constructed

• Which files are allowed

• Whether user input influences inclusion

• Whether execution is possible

63. File Upload Security

File uploads create a major trust boundary.

User File
   ↓
Upload Handler
   ↓
Storage
   ↓
Processing

Questions include:

• Which file types are allowed?

• How is type validated?

• Where are files stored?

• Can uploaded content execute?

• Are filenames controlled?

• Is malware scanning used?

• Can other users access the file?

64. File Extension Validation

Do not assume checking the visible extension is sufficient.

Applications may need to validate:

Extension

Content Type

File Signature

File Content

Storage Location

The exact controls depend on the business requirement.

65. Secure File Storage

A safer design may follow:

Upload
  ↓
Validation
  ↓
Rename
  ↓
Non-Executable Storage
  ↓
Controlled Retrieval

Separating uploaded content from executable application directories reduces risk.

66. XML Security

Applications processing XML may introduce XML-specific risks.

Review:

• Parser configuration

• External entities

• Schema validation

• Resource handling

The important question is how untrusted XML is processed.

67. XXE

XML External Entity weaknesses may occur when insecure parser configurations process attacker-controlled external entity definitions.

Potential impacts may include:

• Local file access

• Server-side requests

• Resource exhaustion

Modern parsers may disable dangerous behaviour by default, but validation is still required.

68. Server-Side Template Injection

Applications sometimes use template engines to generate dynamic content.

If user input is interpreted as template code rather than data, unexpected server-side behaviour may occur.

Conceptually:

User Input
    ↓
Template Engine
    ↓
Server-Side Evaluation

The impact depends on the engine and configuration.

69. Insecure Deserialization

Applications may serialize complex data and later reconstruct it.

If untrusted serialized data is processed insecurely, the application may perform unintended operations.

Assess:

• Data source

• Integrity protection

• Allowed types

• Deserialization behaviour

70. Information Disclosure

Applications may expose:

Stack Traces

Internal Paths

Software Versions

Source Code

Configuration

Credentials

Internal Hostnames

Debug Information

Small disclosures can assist larger attack paths.

71. Error Handling

Weak:

Database connection failed:
server=db-prod-01
username=app_admin

Better:

An unexpected error occurred.

Detailed diagnostic information should generally remain in protected server-side logs rather than being exposed to users.

72. Debug Functionality

Production applications may accidentally expose:

Debug Consoles

Test Endpoints

Diagnostic Pages

Development Tools

Verbose Errors

These can significantly increase attack surface.

73. Security Misconfiguration

Common examples include:

Default Accounts

Directory Listing

Debug Mode

Unnecessary Services

Weak Headers

Exposed Administrative Interfaces

Insecure Cloud Storage

Excessive Permissions

Configuration security is a major part of application testing.

74. Authentication vs Authorization

Never confuse these.

A user may be:

Successfully Authenticated

but still:

Not Authorised

to access a particular object or function.

Many serious application vulnerabilities occur after successful login.

75. Business Logic Vulnerabilities

Business logic flaws occur when legitimate application functions can be used in unintended ways.

Examples:

• Reusing one-time discounts

• Bypassing transaction limits

• Skipping workflow steps

• Manipulating quantities

• Repeating sensitive operations

• Changing transaction state

Automated scanners often struggle to identify these issues.

76. Understand the Intended Workflow

Suppose:

Select Product
     ↓
Add to Cart
     ↓
Payment
     ↓
Order Confirmation

Ask:

Can payment be skipped?

Can price be changed?

Can quantity become invalid?

Can confirmation be replayed?

Business logic testing requires understanding the application.

77. Workflow Bypass

A process may be intended as:

Request
  ↓
Manager Approval
  ↓
Finance Approval
  ↓
Execution

If the execution endpoint can be called directly:

User
 ↓
Execution

the workflow may be bypassed.

78. Race Conditions

Applications may fail when multiple operations occur simultaneously.

Conceptually:

Request A ─┐
           ├──→ Shared State
Request B ─┘

Potential consequences include:

• Duplicate transactions

• Limit bypass

• Inventory inconsistencies

• Multiple redemptions

Testing should be controlled to avoid business disruption.

79. API Security

Modern applications increasingly depend on APIs.

Architecture:

Web / Mobile Client
        ↓
API Gateway
        ↓
Backend API
        ↓
Services
        ↓
Database

Testing the frontend alone may miss the real attack surface.

80. REST APIs

REST APIs commonly use:

GET

POST

PUT

PATCH

DELETE

and exchange data using formats such as JSON.

Example:

GET /api/v1/users/1001 HTTP/1.1
Authorization: Bearer <token>

Understand every endpoint and authorization decision.

81. API Inventory

Create:

Method	Endpoint	Authentication	Purpose
GET	/api/users/me	User	Profile
GET	/api/orders/{id}	User	Order
POST	/api/orders	User	Create order
DELETE	/api/users/{id}	Admin	Delete user

Then test whether actual authorization matches intended authorization.

82. API Object-Level Authorization

APIs commonly expose object identifiers.

Example:

/api/invoices/5001

The API must verify that the current identity is authorised to access invoice 5001.

Do not rely on the identifier being difficult to guess.

83. API Function-Level Authorization

Suppose:

DELETE /api/users/100

is intended only for administrators.

The backend must enforce this requirement regardless of whether the normal user interface exposes the function.

84. Mass Assignment

Applications may automatically map request fields into backend objects.

Suppose a profile update expects:

{
  "name": "Lab User"
}

but the backend also accepts sensitive properties it should not permit users to modify.

The security issue is uncontrolled field binding.

85. Excessive Data Exposure

An API may return more information than the client needs.

Example:

{
  "name": "Lab User",
  "email": "user@example.lab",
  "internalRole": "admin-review",
  "internalId": "12345"
}

Even if the frontend hides fields, the API response itself may expose them.

86. API Rate Limiting

Sensitive operations may require controls against excessive automated requests.

Examples:

Login

Password Reset

OTP Validation

Search

Resource Creation

Expensive AI/API Operations

Rate limiting should align with the abuse scenario.

87. API Authentication Tokens

APIs may use:

• API keys

• Session cookies

• Bearer tokens

• OAuth access tokens

• JWTs

Treat tokens as credentials.

Assess:

Issuance

Scope

Expiration

Revocation

Storage

Authorization

88. JWT

JSON Web Tokens commonly contain structured claims.

Conceptually:

Header
   .
Payload
   .
Signature

Do not assume a JWT is secure merely because it is encoded.

Security depends on:

• Signature validation

• Algorithm handling

• Key management

• Claim validation

• Expiration

• Authorization

89. OAuth and OIDC

Modern applications often delegate identity.

Simplified:

User
 ↓
Application
 ↓
Identity Provider
 ↓
Authentication
 ↓
Token
 ↓
Application

Testing requires understanding:

• Redirects

• Clients

• Tokens

• Scopes

• State

• Identity claims

Do not treat OAuth as simply another password form.

90. GraphQL

GraphQL applications may expose a single endpoint supporting many queries and mutations.

Review:

• Authentication

• Object authorization

• Function authorization

• Query complexity

• Data exposure

• Introspection configuration

The same core authorization principles still apply.

91. WebSockets

Applications may maintain persistent bidirectional connections.

Conceptually:

Browser
   ⇄
WebSocket
   ⇄
Server

Review:

• Authentication

• Authorization

• Message validation

• Session handling

Do not assume normal HTTP controls automatically protect WebSocket messages.

92. Webhooks

Applications may receive server-to-server notifications.

Example:

Payment Provider
       ↓
Webhook
       ↓
Application

Questions include:

• How is the sender authenticated?

• Is message integrity verified?

• Can events be replayed?

• Are duplicate events handled safely?

93. CORS

Cross-Origin Resource Sharing controls whether browser-based applications can access resources across origins.

Assess CORS within the application’s authentication and data model.

Do not report permissive headers without demonstrating meaningful impact.

94. Same-Origin Policy

Browsers normally restrict how scripts from one origin interact with another.

An origin generally considers:

Scheme

Host

Port

Understanding the same-origin policy is essential for browser-based security testing.

95. Clickjacking

Applications may need protection against being embedded inside malicious pages where users could be tricked into interacting with hidden interface elements.

Risk depends on whether sensitive actions can be meaningfully abused.

96. Open Redirects

Applications sometimes redirect users based on supplied URLs.

An unrestricted redirect may support:

• Phishing

• Trust abuse

• Authentication-flow attacks

Evaluate actual impact rather than reporting every redirect as high severity.

97. Host Header Security

Some applications use the HTTP Host header when constructing:

• Links

• Reset URLs

• Routing decisions

Unsafe trust in user-controlled host information may create security issues.

Understand how the application uses the value before concluding vulnerability.

98. Cache Security

Modern applications may sit behind:

CDN

Reverse Proxy

Application Cache

Caching introduces questions around:

• Sensitive responses

• Cache keys

• Authentication

• User-specific data

A caching layer should not accidentally serve one user’s sensitive response to another.

99. Reverse Proxies and Load Balancers

Architecture may look like:

Internet
   ↓
Reverse Proxy
   ↓
Load Balancer
   ↓
Application

Security behaviour may differ depending on which layer processes:

• Headers

• Authentication

• TLS

• Routing

• Client IP information

Architecture matters.

100. Web Application Firewalls

A WAF can provide useful protection.

But:

WAF
 ≠
Secure Application

A WAF may reduce some exploitability while underlying vulnerabilities remain.

Assess both:

Application Weakness
       +
Compensating Control

101. Cloud-Native Web Applications

Modern applications may interact with:

Object Storage

Managed Databases

Serverless Functions

Secrets Managers

Message Queues

Cloud APIs

A web vulnerability can therefore become a cloud attack path.

102. Application Workload Identity

Consider:

Application
   ↓
Cloud Workload Identity
   ↓
Cloud APIs

If the application is compromised, the attacker’s effective permissions may become those of the workload identity.

Least privilege matters.

103. Web-to-Cloud Attack Path

Example:

Web Vulnerability
      ↓
Application Compromise
      ↓
Workload Identity
      ↓
Cloud Storage
      ↓
Sensitive Data

The web finding may therefore have cloud-level impact.

104. Secrets in Applications

Look for insecure storage of:

Database Passwords

API Keys

Cloud Credentials

Private Keys

Tokens

Potential locations include:

• Source code

• Configuration

• Environment variables

• Backups

• Client-side JavaScript

Do not unnecessarily expose discovered secrets in evidence.

105. Source Code Exposure

If source code is unintentionally accessible, it may reveal:

Application Logic

Internal Endpoints

Credentials

Security Controls

Business Logic

Dependencies

The significance depends on what is exposed.

106. Dependency Security

Applications depend on:

Libraries

Frameworks

Packages

Plugins

Containers

Outdated dependencies may contain known vulnerabilities.

But dependency scanning alone does not replace application testing.

107. Software Supply Chain

Consider:

Developer
   ↓
Source Repository
   ↓
CI/CD
   ↓
Dependencies
   ↓
Build
   ↓
Application

A weakness anywhere in this pipeline can affect application security.

108. Administrative Interfaces

Look for:

/admin

/management

/debug

/console

But do not assume a discovered admin page is automatically a vulnerability.

Ask:

Who can reach it?

How is authentication enforced?

Is MFA present?

What functionality exists?

109. Hidden Functionality

Security through obscurity is not sufficient.

An endpoint may not appear in navigation but still remain accessible.

Example:

Normal UI
   X
Admin Feature

while:

Direct Request
     ↓
Admin Endpoint

still succeeds.

This becomes an authorization problem.

110. Test Multiple Roles

Where authorised test accounts are provided, compare:

Anonymous

User A

User B

Manager

Administrator

Role comparison is one of the strongest ways to identify authorization weaknesses.

111. Build a Request Baseline

Before modifying requests, capture normal behaviour.

Example:

Normal Request
      ↓
Normal Response

Then:

Modified Request
      ↓
Changed Response

The difference provides evidence.

112. Change One Thing at a Time

When possible:

Baseline
   ↓
Change One Parameter
   ↓
Observe

Changing many parameters simultaneously makes results difficult to interpret.

This is hypothesis-driven testing.

113. Input Testing Methodology

For each parameter:

Identify
   ↓
Understand Purpose
   ↓
Determine Expected Format
   ↓
Test Boundary Conditions
   ↓
Test Unexpected Input
   ↓
Observe Processing

This produces more disciplined testing than random payload insertion.

114. Test Server-Side Assumptions

Suppose the UI limits quantity to:

1–10

Ask:

Does the server enforce the same rule?

Client-side validation can often be bypassed.

Security controls must exist where trust decisions are made.

115. Test State Transitions

Applications often contain states.

Example:

Draft
  ↓
Submitted
  ↓
Approved
  ↓
Paid

Ask:

Can a user move directly from Draft to Paid?

Can an approved object be modified?

Can completed operations be replayed?

This is business logic testing.

116. Test Object Ownership

For every object:

Profile

Order

Invoice

Document

Ticket

Project

ask:

Who owns it?

Who may read it?

Who may modify it?

Who may delete it?

This makes authorization testing systematic.

117. Test Sensitive Actions

Identify high-impact actions such as:

Change Email

Change Password

Add MFA Device

Transfer Funds

Delete Account

Create Administrator

Modify Permissions

Generate API Key

Then examine whether additional protections are appropriate.

118. Step-Up Authentication

Some high-risk actions may require stronger verification.

Conceptually:

Authenticated Session
       ↓
Sensitive Action
       ↓
Additional Verification
       ↓
Execution

Whether this is required depends on the application’s risk model.

119. Multi-Tenant Applications

SaaS applications may contain multiple customers.

Architecture:

Tenant A
   X
Tenant B

Tenant isolation is a critical security boundary.

Test whether identities, objects, APIs, storage, and administrative functions preserve that separation.

120. Tenant Isolation Failure

Potential attack path:

Tenant A User
      ↓
Object Identifier Manipulation
      ↓
Tenant B Data

This may represent a serious confidentiality breach.

121. Third-Party Integrations

Applications frequently trust:

Payment Providers

Identity Providers

Email Services

Storage Providers

Analytics Platforms

AI Services

Ask:

How is the integration authenticated?

What data is shared?

What happens if the integration is compromised?

122. Application Attack Paths

Do not stop at isolated vulnerabilities.

Example:

Information Disclosure
       ↓
Valid Username
       ↓
Weak Password Reset
       ↓
Account Takeover
       ↓
Authorization Weakness
       ↓
Administrative Function

The chain represents the real security story.

123. Another Attack Path

File Upload
   ↓
Application Compromise
   ↓
Configuration Access
   ↓
Database Credential
   ↓
Sensitive Database

Individual findings should be understood in context.

124. Attack Path Worksheet

For each path record:

Entry Point

Initial Weakness

Identity Obtained

Privilege

Trust Relationship

Next System

Critical Asset

Impact

This becomes useful during reporting.

125. Stop at Sufficient Proof

Suppose you demonstrate unauthorized access to another user’s account record.

You do not need to retrieve hundreds of records.

Use:

Minimum Evidence
      ↓
Maximum Clarity

Professional testing minimises unnecessary exposure.

126. Evidence Collection

Useful web evidence includes:

HTTP Request

HTTP Response

Relevant Screenshot

User / Role

Endpoint

Parameter

Timestamp

Impact

Capture enough information for another professional to understand the finding.

127. Sanitise Evidence

Remove unnecessary:

• Passwords

• Tokens

• Session IDs

• Personal information

• Customer data

Sensitive evidence should be protected.

128. Evidence Example

Evidence ID:
WEB-EV-012

Endpoint:
/api/orders/1002

Authenticated Role:
Standard User A

Observation:
The API returned an order belonging to User B.

Result:
Object-level authorization was not enforced.

This clearly supports the finding.

129. Finding Structure

Use:

Finding ID

Title

Severity

Affected Component

Observation

Evidence

Attack Scenario

Impact

Recommendation

Keep observations factual.

130. Example Finding — Broken Object-Level Authorization

WEB-001 — Users Can Access Other Customers’ Order Records

Observation

The assessment identified that authenticated users could modify the order identifier within the API request and retrieve order records belonging to other users.

Attack Scenario

An authenticated attacker could enumerate accessible identifiers and obtain information associated with other customer accounts.

Impact

Successful exploitation could result in unauthorised disclosure of customer information and violation of tenant or account boundaries.

Recommendation

Implement server-side object-level authorization for every request using the authenticated identity and the ownership or access policy associated with the requested object.

131. Example Finding — Weak File Upload Controls

WEB-002 — Uploaded Files Are Stored in an Executable Application Location

Observation

The application accepted user-controlled files and stored them within a web-accessible location capable of processing executable content.

Risk

An attacker able to upload specially crafted content could potentially cause the application server to process unintended executable content.

Recommendation

Store uploaded files outside executable application directories, validate file type and content, generate server-controlled filenames, restrict permissions, and serve uploaded content through controlled retrieval mechanisms.

132. Example Finding — Sensitive Debug Information

WEB-003 — Production Application Exposes Detailed Error Information

Observation

Malformed requests caused the application to return detailed server-side error information containing internal application paths and technology details.

Risk

The information could assist attackers in understanding the application architecture and developing more targeted attacks.

Recommendation

Return generic error messages to users while recording detailed diagnostic information only within protected server-side logging systems.

133. Severity Analysis

Do not rate findings based solely on vulnerability name.

Consider:

Exploitability

Authentication Required

User Interaction

Data Sensitivity

Privilege Obtained

Affected Users

Internet Exposure

Blast Radius

Existing Controls

Context determines risk.

134. Root Cause Analysis

Suppose you find:

IDOR in Orders

IDOR in Documents

IDOR in Tickets

The systemic issue may be:

Inconsistent server-side object authorization architecture

The strongest recommendation addresses the systemic cause.

135. Security Themes

Multiple findings may combine into themes such as:

Weak Authentication

Broken Authorization

Unsafe Input Handling

Insecure File Processing

Excessive Information Exposure

Weak API Security

Insufficient Secure Development Practices

Themes help leadership understand systemic problems.

136. Remediation Strategy

Recommendations should target:

Root Cause
   ↓
Secure Design
   ↓
Implementation
   ↓
Testing
   ↓
Continuous Assurance

Do not simply recommend adding a WAF to every application vulnerability.

137. Secure Development Lifecycle

Repeated application vulnerabilities may indicate weaknesses in:

Requirements

Architecture

Development

Code Review

Testing

Deployment

Monitoring

The long-term remediation may therefore involve the software development lifecycle.

138. Developer-Focused Recommendations

Recommendations should help engineering teams understand what must change.

Example:

Instead of:

Fix SQL injection.

Use:

Replace dynamically concatenated SQL queries with parameterized queries across the affected data-access layer and add automated security tests covering untrusted database inputs.

Specific guidance is more useful.

139. Retesting

After remediation:

Original Finding
      ↓
Remediation
      ↓
Retest
      ↓
Fixed / Partially Fixed / Not Fixed

Do not simply confirm that the vulnerable page looks different.

Validate the underlying control.

140. Web Application Security Report

A typical report may include:

Executive Summary

Scope

Application Overview

Methodology

Authentication Assessment

Authorization Assessment

Input Security

API Security

Business Logic

Attack Paths

Detailed Findings

Recommendations

Appendices

The exact structure depends on the engagement.

141. Executive Reporting

Executives generally do not need:

Payloads

Raw Requests

Tool Screenshots

They need:

What Was Assessed?

What Important Risks Exist?

What Business Processes Are Affected?

What Should Be Fixed First?

Translate technical findings into security outcomes.

142. Technical Reporting

Engineering teams may need:

• Endpoint

• Request

• Response

• User role

• Parameter

• Technical explanation

• Remediation guidance

Provide sufficient detail without unnecessarily exposing sensitive data.

143. Web Application Testing Checklist

[ ] Scope confirmed
[ ] Application mapped
[ ] Technologies identified
[ ] Subdomains reviewed
[ ] Content discovered
[ ] Inputs mapped
[ ] Authentication reviewed
[ ] Password reset reviewed
[ ] MFA workflow reviewed
[ ] Sessions reviewed
[ ] Cookie security reviewed
[ ] Horizontal authorization tested
[ ] Vertical authorization tested
[ ] Object authorization tested
[ ] Function authorization tested
[ ] SQL injection considered
[ ] Command injection considered
[ ] XSS considered
[ ] CSRF considered
[ ] SSRF considered
[ ] Path traversal considered
[ ] File upload reviewed
[ ] XML processing reviewed
[ ] Template processing reviewed
[ ] Error handling reviewed
[ ] Debug functionality reviewed
[ ] Business logic tested
[ ] State transitions reviewed
[ ] Race conditions considered
[ ] API inventory created
[ ] API authentication reviewed
[ ] API authorization reviewed
[ ] Excessive data exposure reviewed
[ ] Rate limiting reviewed
[ ] Tokens reviewed
[ ] Multi-tenant isolation reviewed
[ ] Third-party integrations reviewed
[ ] Cloud integrations reviewed
[ ] Secrets handling reviewed
[ ] Attack paths developed
[ ] Evidence collected
[ ] Findings validated
[ ] Root causes identified
[ ] Recommendations developed
[ ] Retesting approach defined

144. Build Your Web Application Security Toolkit

Create:

Web Application Security Toolkit/
│
├── 01 Web Scope Template
├── 02 Application Mapping Worksheet
├── 03 HTTP Reference
├── 04 Content Discovery Checklist
├── 05 Technology Fingerprinting
├── 06 Input Mapping Worksheet
├── 07 Authentication Checklist
├── 08 Session Security Checklist
├── 09 Authorization Matrix
├── 10 Injection Testing Checklist
├── 11 XSS Checklist
├── 12 File Upload Checklist
├── 13 SSRF Checklist
├── 14 API Inventory
├── 15 API Security Checklist
├── 16 Business Logic Worksheet
├── 17 Attack Path Worksheet
├── 18 Evidence Log
├── 19 Finding Template
└── 20 Web Security Report Template

145. Practical Lab Scenario

Assume an isolated training application:

Customer Portal
│
├── Login
├── Profile
├── Orders
├── Documents
└── API

You receive two test accounts:

User A

User B

Your mission:

Determine whether the application correctly protects customer information and functionality between accounts.

146. Step 1 — Browse Normally

Login as User A.

Understand:

Profile

Orders

Documents

Account Settings

Do not begin manipulating requests until you understand normal behaviour.

147. Step 2 — Capture Requests

Suppose viewing an order produces:

GET /api/orders/1001 HTTP/1.1
Host: shop.lab
Cookie: session=<redacted>

Record the endpoint.

148. Step 3 — Form a Hypothesis

Observation:

Order identifiers appear in the URL.

Hypothesis:

The backend may rely on the identifier without validating ownership.

Now test the hypothesis using only the provided lab accounts.

149. Step 4 — Establish User B’s Test Object

Using User B’s authorised lab account, identify a test order:

Order 1002

Return to User A.

150. Step 5 — Controlled Authorization Test

As User A, request the User B test object.

Possible secure result:

403 Forbidden

Possible vulnerable result:

200 OK
Order 1002

The second result demonstrates a broken authorization boundary.

151. Step 6 — Stop at Proof

You have demonstrated the issue using two controlled test accounts.

There is no need to enumerate unrelated customer records.

This is sufficient evidence.

152. Step 7 — Build the Attack Path

Authenticated User
      ↓
Predictable Object Reference
      ↓
Missing Ownership Check
      ↓
Another Customer's Order
      ↓
Customer Data Exposure

The real weakness is missing server-side authorization.

153. Step 8 — Record Evidence

WEB-EV-001
User A normal order request

WEB-EV-002
User B controlled test order

WEB-EV-003
User A retrieving User B's order

Sanitise session identifiers.

154. Step 9 — Develop Recommendation

Recommend:

Authenticated Identity
       ↓
Requested Object
       ↓
Server-Side Authorization Check
       ↓
Allow / Deny

Every object request should enforce authorization.

155. Step 10 — Consider Systemic Risk

Now ask:

Are the same authorization controls missing from documents?

Profiles?

Tickets?

API resources?

One finding may indicate a broader architectural weakness.

156. Web Hacker Mindset

When you see:

?id=1001

do not think only:

Change the ID.

Think:

What Object?

Who Owns It?

Who May Read It?

Who May Modify It?

Who May Delete It?

Where Is Authorization Enforced?

When you see:

POST /upload

think:

Which Files?

How Validated?

Where Stored?

Can They Execute?

Who Can Retrieve Them?

How Are They Processed?

When you see:

Authorization: Bearer ...

think:

Who Issued It?

Which Identity?

Which Scope?

Which Claims?

When Does It Expire?

What Does the Backend Trust?

This questioning process is the skill.

157. Common Web Testing Mistakes

Avoid:

Running a Scanner and Calling It a Penetration Test

Automation cannot understand the entire application.

Testing Before Understanding the Workflow

Business logic requires context.

Focusing Only on Injection

Modern applications frequently fail at authorization and identity boundaries.

Ignoring APIs

The API may expose more functionality than the frontend.

Testing Only Anonymous Users

Many critical vulnerabilities exist after authentication.

Testing Only One Role

Role comparison is essential for authorization testing.

Treating Every Missing Header as High Risk

Evaluate actual impact.

Downloading Excessive Sensitive Data

Stop once sufficient proof exists.

Reporting Payloads Instead of Risk

Explain what the weakness means.

158. The Most Important Web Security Questions

For every application ask:

Architecture

How does this application work?

Entry Points

Where can users provide data?

Authentication

How does the application know who the user is?

Session

How is authentication state maintained?

Authorization

How does the server decide what the user may access?

Data

What sensitive information is processed?

Trust

Which backend systems does the application trust?

APIs

Which functionality exists outside the visible UI?

Business Logic

Which assumptions does the workflow make?

Cloud

Which cloud identities and resources can the application access?

Impact

What happens if the application is compromised?

159. Think Beyond the Application

The complete attack path may be:

Internet
   ↓
Web Application
   ↓
Application Vulnerability
   ↓
Server
   ↓
Credential
   ↓
Internal Network
   ↓
Active Directory

or:

Internet
   ↓
Cloud Application
   ↓
SSRF / Application Compromise
   ↓
Workload Identity
   ↓
Cloud Control Plane

Web Application Security connects directly with:

• Network security

• Identity security

• Active Directory

• Cloud security

160. Definition of Success

A successful web application assessment is not:

I found XSS.

It is not:

My scanner produced 42 alerts.

It is not:

I collected hundreds of HTTP requests.

Success is being able to explain:

How the Application Works
        ↓
Where Trust Exists
        ↓
Which Security Control Failed
        ↓
How It Can Be Abused
        ↓
What the Attacker Gains
        ↓
What Business Process Is Affected
        ↓
How the Root Cause Should Be Fixed

That is professional Web Application Security Testing.

Key Takeaways

Web applications should be treated as interconnected systems rather than collections of URLs.

Remember:

Understand the application before attacking it.

Understand HTTP deeply.

Map every important input.

Authentication and authorization are different controls.

Never rely on client-side controls for security decisions.

Test authorization using multiple controlled identities.

APIs are part of the application attack surface.

Business logic vulnerabilities require human reasoning.

Treat uploaded files and external inputs as untrusted.

Application vulnerabilities can become network, identity, and cloud attack paths.

Stop when sufficient evidence has been obtained.

Recommendations should address the root cause, not merely the payload.

Your core methodology is:

Scope
  ↓
Understand Architecture
  ↓
Map Application
  ↓
Map Inputs
  ↓
Understand Identity
  ↓
Test Authentication
  ↓
Test Sessions
  ↓
Test Authorization
  ↓
Test Input Handling
  ↓
Test Business Logic
  ↓
Assess APIs
  ↓
Develop Attack Paths
  ↓
Validate Impact
  ↓
Collect Evidence
  ↓
Report
  ↓
Recommend

The strongest web application security testers do not simply memorise payloads.

They understand:

HTTP, application architecture, identity, authorization, data flows, trust boundaries, business logic, APIs, backend systems, and attack paths.

What’s Next?

➡️ 04 — Active Directory Security

In the next module, you will move from application security into one of the most important enterprise attack surfaces:

Microsoft Active Directory.

You will learn how to understand and assess:

• Active Directory architecture

• Domains

• Domain Controllers

• Users

• Groups

• Computers

• Authentication

• Kerberos

• NTLM

• LDAP

• Group Policy

• Service accounts

• Privileged groups

• Password policies

• Permissions

• Trust relationships

• Credential exposure

• Privilege escalation paths

• Lateral movement

• Active Directory attack paths

• Evidence collection

• Active Directory security findings

You will move from thinking about individual hosts to thinking about identity relationships across an enterprise environment.

The core question becomes:

If one enterprise identity or workstation is compromised, what path could lead toward privileged control of the environment?