Lab 12 Web Input Validation Security Assessment.

Mission Overview

Welcome to Lab 12 — Web Input Validation Security Assessment.

In Lab 10, you mapped the web application’s attack surface. In Lab 11, you assessed authentication and session security.

Now you will examine another fundamental security boundary:

What happens when the application receives data controlled by the user?

Almost every modern web application accepts input through search fields, forms, URLs, APIs, JSON requests, headers, cookies, identifiers, file names, and account settings.

The security principle is simple:

Never assume client-controlled data is trustworthy.

In this lab, you will safely assess how an authorized training application validates, processes, rejects, stores, and returns user-controlled input.

The goal is not to run destructive payloads or compromise the server. Instead, you will use controlled test values to determine whether validation controls exist and where deeper testing may be required.

Mission Goal: Map application input surfaces, test validation boundaries with benign values, identify inconsistent or missing validation, distinguish unusual behavior from validated security findings, and produce an Input Validation Assessment Register.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	90–120 minutes
Primary Skill	Web Input Validation Assessment
Secondary Skill	Application Data-Flow Analysis
Environment	Authorized Training Web Application
Tools	Browser, Developer Tools, Burp Suite Community, curl
Starting Point	Lab 10 Endpoint & Parameter Inventory
Testing Style	Controlled, Non-Destructive
Primary Outcome	Input Validation Assessment Register
Evidence	Requests, responses, screenshots, behavior observations
Safety Level	Authorized Lab Only

Learning Objectives

By completing this lab, you will be able to:

understand input validation
distinguish client-side and server-side validation
identify application input surfaces
classify input types
identify expected data formats
test minimum and maximum boundaries
assess numeric validation
assess text-field validation
assess structured input
review URL and path parameters
inspect API/JSON validation
understand allowlisting and denylisting
distinguish validation from sanitization
understand encoding and escaping
recognize reflected and stored data flows
safely identify error-handling weaknesses
identify inconsistent validation
create validation test cases
document findings and remediation

Core Methodology

Use:

Input → Expected Format → Validation → Processing → Output → Evidence → Security Impact

A professional tester does not begin with random payloads.

Instead:

Identify Input
      ↓
Understand Purpose
      ↓
Define Expected Values
      ↓
Test Boundaries
      ↓
Observe Response
      ↓
Determine Server Behavior
      ↓
Correlate Evidence
      ↓
Classify Finding

The central question is:

Does the application enforce its security assumptions on the server, regardless of what the client submits?

Lab Architecture

                GHC Ethical Hacking Lab
                       │
                   Kali Linux
                       │
              Browser + Burp Suite
                       │
                       ▼
              Training Web Application
                       │
       ┌───────────────┼────────────────┐
       ▼               ▼                ▼
     Forms           URLs              APIs
       │               │                │
       ▼               ▼                ▼
     Input         Parameters          JSON
       │               │                │
       └───────────────┼────────────────┘
                       ▼
                   Validation
                       │
                 ┌─────┴─────┐
                 ▼           ▼
              Accept       Reject
                 │
                 ▼
              Process
                 │
                 ▼
               Output

Part 1 — Confirm Scope

Record:

Application:

Target URL:

Authorized Account:

Authorized Roles:

Authorized Endpoints:

API Testing:
Allowed / Not Allowed

File Upload Testing:
Allowed / Not Allowed

Input Manipulation:
Allowed

Destructive Testing:
Not Permitted

Excluded Functions:

Assessment Start:

Use only the designated training application.

Part 2 — Establish Rules of Engagement

Permitted

benign boundary testing
empty values
unexpected but harmless text
permitted long-string tests
numeric boundary tests
changing your own request parameters
inspecting client-side validation
submitting modified requests to the lab
testing malformed but non-destructive structured data
observing error handling

Not Required

destructive SQL injection
operating-system command execution
server compromise
data extraction
reading another user’s information
destructive file operations
denial-of-service testing
persistence
bypassing authorization boundaries

The objective is:

Understand how input is handled before moving into vulnerability-specific testing.

Part 3 — Create the Workspace

Create:

Ethical-Hacking-Labs/
└── Lab-12/
    ├── Notes/
    ├── Evidence/
    │   ├── Forms/
    │   ├── Parameters/
    │   ├── Boundaries/
    │   ├── API/
    │   ├── Errors/
    │   └── Output/
    ├── Requests/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-12-Investigation-Journal.md

Suggested structure:

# Lab 12 — Web Input Validation Security Assessment

## Mission Objective

## Scope

## Input Inventory

## Expected Formats

## Client-Side Validation

## Server-Side Validation

## Boundary Testing

## Numeric Inputs

## Text Inputs

## URL Parameters

## Structured Input

## API Validation

## Output Handling

## Error Handling

## Validation Gaps

## Positive Controls

## Findings

## Evidence

## Recommendations

## Lessons Learned

Part 4 — Import the Input Inventory

Start with Lab 10.

Example:

ID	Endpoint	Parameter	Location	Expected Type
INPUT-01	`/search`	`q`	Query	Text
INPUT-02	`/profile`	`name`	Body	Text
INPUT-03	`/profile`	`email`	Body	Email
INPUT-04	`/products`	`id`	Query	Integer
INPUT-05	`/api/search`	`q`	JSON/query	Text

Do not test randomly.

Create a test case for each important input.

Part 5 — Classify Input Sources

Application input can originate from many locations:

User Input
   │
   ├── Form Fields
   ├── Query Parameters
   ├── Path Parameters
   ├── JSON Properties
   ├── Cookies
   ├── Headers
   ├── File Names
   └── Client-Side State

Anything controlled by the client should be treated as potentially untrusted.

Part 6 — Identify Expected Data Types

For every input, ask:

What does the application expect?

Examples:

Input	Expected Type
Name	Text
Age	Integer
Email	Email address
Quantity	Positive integer
Date	Date
Product ID	Identifier
Search	Free text

This gives you a baseline for meaningful validation testing.

Part 7 — Define Validation Rules

Create:

Input	Type	Required	Min	Max	Expected Format
Username	Text	Yes	3	50	Application-defined
Email	Email	Yes	—	254	Valid email
Quantity	Integer	Yes	1	100	Positive integer
Search	Text	No	0	App-defined	Free text

Use the application’s actual documented or observed rules.

Do not invent production requirements.

Part 8 — Establish a Known-Good Request

Before modifying anything, capture a valid request.

Example:

GET /search?q=security

Record:

Request:

Input:

Response Code:

Response Length:

Application Message:

Result:

This becomes your control sample.

Part 9 — Use One-Variable-at-a-Time Testing

Avoid changing five parameters simultaneously.

Use:

Known Good Request
       ↓
Change One Input
       ↓
Send Request
       ↓
Observe Difference

This makes evidence much easier to interpret.

Part 10 — Test Empty Input

Where safe and appropriate, submit:

<empty>

Observe whether the application:

accepts it
rejects it
substitutes a default
returns a validation message
generates an error

Record:

Input	Empty Accepted	Response	Expected
Name
Email
Search

An optional search field may legitimately accept empty input.

Context matters.

Part 11 — Test Whitespace

A value containing only spaces can behave differently from an empty field.

For example:

"     "

Ask:

Does the application trim unnecessary whitespace before validation?

Record the result.

Part 12 — Test Leading and Trailing Whitespace

For an authorized training value:

"  student  "

Observe whether it becomes:

"student"

or remains unchanged.

Normalization behavior matters because different components may interpret the same value differently.

Part 13 — Test Minimum Length

If an input requires at least three characters, test a shorter benign value.

Example:

ab

Record:

Expected:
Rejected

Observed:

Server Response:

Validation Message:

Part 14 — Test Maximum Length

If the application specifies a maximum length, test the boundary safely.

For example:

Maximum:
50 characters

Test:

49
50
51

characters.

The pattern is:

Below Boundary → Boundary → Above Boundary

Do not send enormous inputs.

Part 15 — Understand Boundary Testing

If the allowed range is:

1–100

use:

These values provide far more useful evidence than random numbers.

Part 16 — Assess Numeric Inputs

Suppose:

quantity=2

is valid.

Within the authorized lab, benign test cases could include:

quantity=0

quantity=-1

quantity=1

quantity=100

quantity=101

based on the application’s expected range.

Observe:

accepted
rejected
normalized
server error
business-rule violation

Part 17 — Test Non-Numeric Input

For an integer field, try a harmless non-numeric value:

quantity=abc

Record whether validation occurs.

The server should not rely only on the browser’s input type.

Part 18 — Understand Client-Side Validation

HTML may contain:

<input type="number" min="1" max="100">

This improves usability.

But the browser is controlled by the user.

Therefore:

Client Validation
      =
Useful UX Control

not:

Client Validation
      =
Security Boundary

Part 19 — Compare Browser and Server Validation

Suppose the browser prevents:

quantity=-1

Capture the normal request in Burp.

Then, only within the training application, change your own request to a benign out-of-range value.

Observe the server response.

If the server accepts it:

Browser Rejects
      +
Server Accepts
      =
Server-Side Validation Gap

This is a fundamental lesson.

Part 20 — Assess Email Validation

For a lab profile field, compare benign values such as:

student@example.test

with malformed values such as:

student

or:

student@

Record:

Client Validation:

Server Validation:

Error Message:

Stored:
Yes / No

Do not use real third-party email addresses.

Part 21 — Assess Enumerated Values

Suppose the application expects:

role=user

or a harmless preference such as:

theme=light

Do not use this lab to change privileges.

Instead, for a non-security-sensitive enumerated field, assess whether the server accepts unsupported values.

Example:

theme=invalid-option

Expected behavior should be predictable and controlled.

Part 22 — Assess Boolean Inputs

Suppose an application uses:

notifications=true

Potential benign tests include:

true
false
invalid

Record how unexpected values are handled.

Part 23 — Assess Date Inputs

If a lab form expects a date:

2026-08-28

safe test cases could include:

valid date

invalid format

impossible date

boundary date

For example:

2026-99-99

should not silently become trusted application data.

Part 24 — Assess URL Query Parameters

From Lab 10:

/search?q=cloud

Capture the request.

Change only the search term using harmless test strings.

Examples:

cloud security

test-value

Observe:

reflection
normalization
encoding
errors
result behavior

Part 25 — Identify Reflected Input

Suppose you submit:

GHC-INPUT-TEST-01

and the response displays:

Search results for GHC-INPUT-TEST-01

Record:

Input:
GHC-INPUT-TEST-01

Reflected:
Yes

Location:
Search results heading

Encoding:
Observed / Unknown

Reflection alone is not a vulnerability.

Part 26 — Identify Stored Input

A profile name, comment, or other authorized training field may be stored.

Use a harmless marker:

GHC-STORED-TEST-01

Then determine whether it appears later.

Conceptually:

Input
  ↓
Application
  ↓
Storage
  ↓
Later Page
  ↓
Output

Again, storage itself is not a vulnerability.

Part 27 — Distinguish Reflected vs Stored Data

Reflected

Request
   ↓
Response

Stored

Request
   ↓
Database/Storage
   ↓
Later Request
   ↓
Response

This distinction becomes important when evaluating output-handling weaknesses.

Part 28 — Understand Validation vs Sanitization

These are not identical.

Validation

Determines whether input is acceptable.

Example:

Expected:
Integer 1–100

Received:
500

Action:
Reject

Sanitization

Transforms data to remove or neutralize unwanted content.

Example conceptually:

Input
 ↓
Transformation
 ↓
Processed Value

Where possible, strong applications validate against clearly defined expected formats.

Part 29 — Understand Encoding

Output encoding protects data when it is inserted into a particular output context.

Conceptually:

Untrusted Data
      ↓
Context-Aware Encoding
      ↓
Safe Output Representation

Different contexts may require different handling:

HTML

HTML Attribute

URL

JavaScript

JSON

Validation and output encoding solve different problems.

Part 30 — Use Harmless Marker Strings

For this lab, use distinctive markers such as:

GHC-INPUT-001

GHC-TEST-ALPHA

GHC-BOUNDARY-01

These allow you to trace data without using executable attack payloads.

Part 31 — Assess Special-Character Handling Safely

Where permitted, use a small harmless string containing punctuation.

For example:

GHC-Test_01-Example

or a simple punctuation sequence approved for the training field.

The goal is to understand:

Accepted?

Rejected?

Encoded?

Normalized?

Error?

You do not need executable XSS, SQL, or command payloads to establish basic validation behavior.

Part 32 — Assess Path Parameters

Suppose the application uses:

/products/10

Document:

Parameter:
10

Expected Type:
Product identifier

Server Validation:

Invalid Identifier Behavior:

Use only harmless invalid identifiers belonging to the training environment.

Do not use this lab to access another user’s resources.

Part 33 — Assess Invalid Object Identifiers

For a public training product:

/products/10

you might compare an obviously nonexistent training identifier:

/products/999999

Observe:

404?

Empty response?

Controlled application message?

Server error?

This tests error handling, not authorization bypass.

Part 34 — Assess JSON Input

If the authorized API accepts:

{
  "name": "Student",
  "quantity": 2
}

establish the known-good request first.

Then change one benign field at a time.

For example:

{
  "name": "Student",
  "quantity": "invalid"
}

Observe whether the API rejects the incorrect type.

Part 35 — Review API Validation Responses

A well-controlled API might return a response indicating that the submitted value is invalid.

Record:

HTTP Status:

Error Type:

Field Identified:

Internal Information Exposed:

Request Rejected:

The exact status code depends on application design.

Part 36 — Test Missing JSON Properties

If a field is required, remove only that field from your training request.

Example:

{
  "name": "Student"
}

when quantity is required.

Record whether:

Request rejected

Default value assigned

Unexpected server error

Request accepted

Part 37 — Test Additional JSON Properties

For an authorized non-sensitive training endpoint, add a harmless unknown property:

{
  "name": "Student",
  "quantity": 2,
  "trainingNote": "GHC-TEST"
}

Observe whether the server:

rejects unknown fields
ignores them
stores them
returns an error

Do not add privilege-related properties such as administrator roles.

Part 38 — Assess Content-Type Handling

Observe the expected request type:

application/json

or:

application/x-www-form-urlencoded

Record whether the server handles unexpected request formats predictably.

Do not attempt parser exploitation.

Part 39 — Review Hidden Form Fields

A browser may submit:

<input type="hidden" name="language" value="en">

Hidden means:

Not normally displayed to the user.

It does not mean:

Trusted by the server.

Use only non-security-sensitive training fields when demonstrating this principle.

Part 40 — Review Disabled Fields

Similarly:

<input disabled>

is a browser behavior.

A client can control the request sent to the server.

Therefore, authorization and critical business rules must be enforced server-side.

Part 41 — Identify Duplicate Validation

Sometimes:

Browser
   ↓
Validation
   ↓
API
   ↓
Validation
   ↓
Application Logic

This is expected.

Client-side validation improves usability.

Server-side validation enforces trust.

Part 42 — Look for Validation Inconsistency

Suppose:

Web Form
Rejects 101

but:

API
Accepts 101

for a maximum value of 100.

You may have found:

Inconsistent server-side validation across application interfaces.

Modern applications often expose the same business function through multiple paths.

Part 43 — Compare Multiple Endpoints

For the same data type, compare:

/profile

/api/profile

/settings

Ask:

Are validation rules consistent everywhere the same information can be changed?

Part 44 — Review Error Handling

Input validation failures should normally produce controlled responses.

Avoid responses exposing unnecessary:

Stack traces

Filesystem paths

Database details

Framework internals

Source code

Internal hostnames

Record any disclosure without attempting to expand it.

Part 45 — Distinguish Validation Error from Server Error

Example:

Invalid quantity
      ↓
400-class response
      ↓
Controlled message

versus:

Invalid quantity
      ↓
500
      ↓
Stack trace

The second deserves further investigation.

Part 46 — Do Not Treat Every 500 as Exploitable

A server error means:

Something unexpected happened.

It does not automatically mean:

The application can be compromised.

Use:

Observation
   ↓
Reproduce Safely
   ↓
Collect Evidence
   ↓
Determine Impact

Part 47 — Assess Input Normalization

Applications may normalize:

Case

Whitespace

Unicode

Dates

Phone numbers

Identifiers

For example:

" Student "

may become:

"Student"

Record normalization where it affects security assumptions.

Part 48 — Understand Canonicalization

Different representations can sometimes mean the same thing.

Conceptually:

Different Input Representations
          ↓
      Normalization
          ↓
     Canonical Value
          ↓
       Validation

Validation should generally operate on the representation the application actually intends to process.

Part 49 — Review File Names Safely

If Lab 10 identified an upload feature and file-upload testing is authorized, use only a benign text file.

Example:

ghc-training.txt

Assess:

File Name Accepted:

Extension Validation:

Size Validation:

Renamed by Server:

Storage Location Exposed:

Error Handling:

Do not upload executable content in this lab.

Part 50 — Test File Size Boundaries

If the application documents:

Maximum file size:
1 MB

use small benign files around the permitted boundary where practical.

Do not upload huge files or intentionally exhaust storage.

Part 51 — Assess Extension Validation

Use only benign formats permitted by the lab.

For example:

.txt

versus another harmless unsupported type.

The objective is simply to determine whether the application enforces its stated file-type policy.

Part 52 — Separate Validation from Authorization

This distinction is critical.

Suppose:

documentId=25

The questions are different:

Validation

Is 25 a syntactically valid document identifier?

Authorization

Is the current user permitted to access document 25?

Lab 12 focuses on the first question.

Authorization becomes the focus of Lab 13.

Part 53 — Separate Validation from Business Logic

Suppose:

quantity=100

is syntactically valid.

But the business rule allows only:

Maximum:
10

Therefore:

Type Validation
     ≠
Business Rule Validation

Applications require both.

Part 54 — Build the Input Data-Flow Map

Example:

                    User
                     │
                     ▼
                   Input
                     │
            ┌────────┼────────┐
            ▼        ▼        ▼
           Form     URL      API
            │        │        │
            └────────┼────────┘
                     ▼
                 Validation
                     │
                     ▼
              Business Logic
                     │
               ┌─────┴─────┐
               ▼           ▼
             Storage      Output
               │           │
               └─────┬─────┘
                     ▼
                  Browser

Mark where validation actually occurs.

Part 55 — Build a Validation Test Matrix

Example:

Input	Valid	Empty	Wrong Type	Boundary	Result
Search	Yes	Yes	N/A	Long	Review
Quantity	Yes	No	Reject	Reject	Good
Email	Yes	Reject	Reject	Review	Good
Product ID	Yes	N/A	Reject	N/A	Good

This provides much stronger evidence than random testing.

Part 56 — Build the Input Validation Register

Use:

ID	Endpoint	Input	Expected	Test	Result	Security Relevance
VAL-01	`/profile`	email	Email	Invalid format	Rejected	Positive
VAL-02	`/order`	quantity	1–10	11	Accepted	Review
VAL-03	`/api/order`	quantity	Integer	Text	500 error	Review
VAL-04	`/search`	q	Text	Marker	Reflected safely	Positive

Part 57 — Classify Results

Use four categories.

Positive Control

Validation works as expected.

Observation

Interesting behavior without demonstrated security impact.

Potential Weakness

Validation appears incomplete and needs further assessment.

Validated Finding

Evidence demonstrates a security weakness and meaningful impact.

This prevents over-reporting.

Part 58 — Finding Example: Missing Server-Side Range Validation

Finding:
Server does not enforce the documented quantity limit.

Observation:
The browser restricts the quantity field to a maximum of 10,
but the authorized training request was modified to submit 11.
The server accepted and processed the value.

Impact:
Business rules enforced only by the client can be bypassed by
direct requests, potentially allowing invalid application state.

Recommendation:
Enforce quantity and business-rule restrictions server-side
regardless of client-side controls.

Part 59 — Finding Example: API Type Validation Failure

Finding:
Unexpected API input produces an uncontrolled server error.

Observation:
A training API property documented as an integer received a
benign text value. The application returned a server error
rather than a controlled validation response.

Impact:
Improper input handling may reduce application reliability and
can expose additional security-relevant behavior.

Recommendation:
Validate API schemas before processing and return controlled
error responses for invalid data.

Part 60 — Finding Example: Excessive Error Disclosure

Finding:
Input validation error exposes internal application details.

Observation:
A malformed training request caused the application to return
internal implementation information unnecessary to the user.

Impact:
Internal technical information may assist an attacker in
understanding application architecture and identifying further
attack opportunities.

Recommendation:
Return generic client-facing errors while retaining detailed
diagnostics only in protected server-side logging.

Part 61 — Positive Finding Example

Positive Control:
Server-side quantity validation successfully enforced.

Evidence:
Values within the permitted range were accepted while values
outside the range were consistently rejected by both the web
interface and API.

Security Value:
Business rules cannot be bypassed simply by modifying the
client-side request.

Part 62 — Prioritize Findings

Consider:

Input Reachability + Processing Context + Authentication + Data Sensitivity + Business Impact + Existing Controls

Example:

Public Input
     +
Server Processing
     +
Missing Validation
     +
Sensitive Business Function
     =
Higher Priority

Do not assign severity based merely on unusual application behavior.

Part 63 — Build the Findings Register

ID	Area	Finding	Severity	Confidence	Status
WEB-IN-01	Quantity	Server range gap	Medium	Confirmed	Open
WEB-IN-02	API	Invalid type causes error	Low/Medium	Confirmed	Open
WEB-IN-03	Email	Server validates format	Positive	Confirmed	Maintain
WEB-IN-04	Error	Internal details exposed	Medium	Confirmed	Open

Severity should reflect the actual training scenario and demonstrated impact.

Part 64 — Remediation Principles

Input-validation remediation generally follows:

1. Define Expected Input

Know exactly what the application requires.

2. Validate Server-Side

Never trust browser enforcement alone.

3. Prefer Allowlisting

Accept known-valid formats where practical.

4. Normalize Consistently

Apply consistent canonical representation before security-sensitive processing.

5. Enforce Length and Range

Reject values outside legitimate boundaries.

6. Enforce Business Rules

Valid syntax does not necessarily mean valid business behavior.

7. Encode Output

Treat untrusted data safely when returning it to different output contexts.

8. Handle Errors Safely

Users need useful errors without internal implementation disclosure.

9. Log Validation Failures

Repeated unusual input can provide useful security telemetry.

Part 65 — Evidence Requirements

Capture:

Evidence 01

Input inventory.

Evidence 02

Expected validation rules.

Evidence 03

Known-good request.

Evidence 04

Empty-value behavior.

Evidence 05

Boundary tests.

Evidence 06

Numeric validation.

Evidence 07

Client-side validation.

Evidence 08

Server-side validation.

Evidence 09

Text-input behavior.

Evidence 10

Reflected marker behavior.

Evidence 11

Stored marker behavior if applicable.

Evidence 12

URL parameter validation.

Evidence 13

API type validation.

Evidence 14

Missing-property handling.

Evidence 15

Error handling.

Evidence 16

File validation if applicable.

Evidence 17

Validation Test Matrix.

Evidence 18

Input Validation Assessment Register.

Part 66 — Mission Challenge

Complete:

Application:

Inputs Identified:

Form Inputs:

Query Parameters:

Path Parameters:

API Inputs:

Required Fields:

Optional Fields:

Numeric Inputs:

Text Inputs:

Structured Inputs:

Client-Side Validation:

Server-Side Validation:

Maximum Length Enforced:

Minimum Length Enforced:

Numeric Range Enforced:

Unexpected Types Rejected:

Missing Required Fields Rejected:

Unknown API Properties:

Input Normalization:

Reflected Data:

Stored Data:

Error Handling:

Internal Error Disclosure:

File Validation:
If applicable

Strongest Validation Control:

Most Significant Validation Gap:

Highest-Priority Input:

Top Remediation Recommendation:

Support conclusions with evidence.

Part 67 — What Not to Do

This lab does not require:

SQL database extraction

Operating-system command execution

Web shell upload

Destructive injection

Sensitive-data extraction

Authentication bypass

Authorization bypass

Accessing another user's records

Large automated fuzzing

Denial-of-service payloads

Extremely large requests

Production-system testing

The mission is:

Understand and validate application trust boundaries safely.

Part 68 — Troubleshooting

Browser Rejects the Test Value

This may indicate client-side validation.

Use Burp only against your authorized lab to determine whether the server independently enforces the same rule.

Application Returns 500

Stop increasing input complexity.

Record:

Input Type:

Expected Behavior:

Observed Response:

Reproducible:
Yes / No

Internal Details:
Yes / No

A 500 response is evidence to investigate, not permission to escalate testing.

Modified Request Is Rejected

That may be exactly the security control you are testing.

Document it as positive evidence.

Input Is Reflected

Do not immediately classify it as XSS.

Record:

Reflected:
Yes

Output Context:

Encoding:
Observed / Unknown

Reflection and executable script injection are not the same thing.

API Rejects Modified JSON

Review the error.

If the API rejects incorrect input safely and consistently, the control may be working correctly.

Mission Deliverables

Complete:

scope confirmed
Lab 10 input inventory imported
inputs classified
expected formats documented
known-good requests captured
client-side validation reviewed
server-side validation reviewed
empty values tested
whitespace handling assessed
minimum boundaries assessed
maximum boundaries assessed
numeric validation assessed
text validation assessed
URL parameters assessed
structured data assessed
API validation reviewed
reflected data identified
stored data identified where applicable
error handling reviewed
business-rule validation reviewed
positive controls documented
Validation Test Matrix completed
findings prioritized
evidence captured
remediation recommendations created
final report completed

Lab Report Template

# Lab 12 — Web Input Validation Security Assessment

## Executive Summary

## Mission Objective

## Scope

## Application Input Architecture

## Input Inventory

## Expected Validation Rules

## Client-Side Validation

## Server-Side Validation

## Boundary Testing

## Text Input Assessment

## Numeric Input Assessment

## URL Parameter Assessment

## Structured Data Assessment

## API Validation

## Data Normalization

## Reflected Data

## Stored Data

## Output Handling

## Error Handling

## File Validation

## Positive Security Controls

## Security Findings

## Risk Prioritization

## Recommendations

## Evidence

## Limitations

## Lessons Learned

## Conclusion

Knowledge Check

Question 1 — Why is client-side validation insufficient?

Because the client is controlled by the user and requests can be sent directly to the server without following browser-side restrictions.

Question 2 — What is server-side validation?

Validation performed by the trusted server before untrusted data is used by application logic.

Question 3 — What is boundary testing?

Testing values immediately below, at, and immediately above expected limits.

For a range of 1–100:

0 → 1 → 100 → 101

Question 4 — What is the difference between validation and encoding?

Validation determines whether input is acceptable. Encoding safely represents data when it is placed into a particular output context.

Question 5 — Does reflected user input automatically mean XSS?

No.

Reflection shows that data returns in a response. Whether it can execute depends on output context and protection.

Question 6 — Does a server error prove a vulnerability?

No.

It demonstrates unexpected behavior requiring investigation and impact analysis.

Question 7 — Why use one-variable-at-a-time testing?

Because it makes it easier to determine which change caused the observed behavior.

Question 8 — Why assess APIs separately from browser forms?

The same business function may use different validation paths, producing inconsistent security controls.

Question 9 — What is the difference between validation and authorization?

Validation asks:

“Is this input acceptable?”

Authorization asks:

“Is this user permitted to perform this action on this resource?”

Question 10 — Why document positive controls?

Because a professional assessment describes the actual security posture, not only weaknesses.

Skills Achieved

After completing this lab, you should understand:

input-surface mapping
input classification
expected-format analysis
client-side validation
server-side validation
boundary testing
numeric validation
text validation
URL parameter validation
structured input
JSON/API validation
validation vs sanitization
output encoding concepts
reflected data
stored data
input normalization
business-rule validation
error-handling assessment
safe file-input assessment
validation test matrices
evidence collection
finding classification
remediation planning

Professional Takeaway

Input-validation testing should not begin with:

“Which payload can I send?”

Begin with:

“What does this application expect, where is that assumption enforced, and what happens when the client violates it?”

The professional methodology is:

Identify → Classify → Baseline → Modify → Observe → Correlate → Validate → Assess Impact → Document

The most important lesson from this lab is:

Browser Says:
"You cannot submit this."
        │
        ▼
Does NOT prove
        │
        ▼
Server Says:
"I will not accept this."

Security decisions must ultimately be enforced within trusted application components.

What’s Next?

➡️ Lab 13 — Web Authorization & Access Control Assessment

You have now assessed:

Lab 10
Attack Surface
      ↓
Lab 11
Authentication & Sessions
      ↓
Lab 12
Input Validation

The next question is:

Once a user is authenticated, what are they actually allowed to access and perform?

In Lab 13, you will assess authorization boundaries using only dedicated lab accounts and resources.

You will examine:

anonymous vs authenticated access
user roles
horizontal authorization
vertical authorization
object ownership
direct object references
protected application functions
API authorization
server-side access enforcement
denied-access behavior
least privilege
authorization evidence

The methodology becomes:

Identity → Role → Resource → Action → Authorization Decision → Evidence

By the end of Lab 13, you should be able to answer:

“Does the application consistently enforce which authenticated users can access which resources and perform which actions?”