04 Web Security Practice

04 Web Security Practice

Welcome to the Web Security Practice Path.

Web applications are one of the largest attack surfaces in modern organizations.

Customer portals, administrative dashboards, APIs, cloud consoles, SaaS platforms, e-commerce applications and internal enterprise systems all rely heavily on web technologies.

To assess them effectively, you first need to understand how web applications actually work.

Do not start by searching for vulnerabilities. Start by understanding the application.

This practice path develops the methodology and thinking required for authorized web application security testing.

Path Objective

By completing this path, you should develop practical understanding of:

• web architecture
• HTTP and HTTPS
• requests and responses
• headers
• cookies
• sessions
• authentication
• authorization
• application mapping
• input handling
• access control
• OWASP security concepts
• API security
• browser security
• web security testing methodology
• evidence collection
• remediation
• reporting

All security testing must remain within TryHackMe, GoHackersCloud Labs, your own intentionally vulnerable applications, or systems for which you have explicit authorization.

Recommended Web Security Journey

Follow this progression:

Web Fundamentals
       ↓
HTTP & HTTPS
       ↓
Requests & Responses
       ↓
Application Mapping
       ↓
Authentication
       ↓
Sessions
       ↓
Access Control
       ↓
Input Handling
       ↓
Common Web Vulnerabilities
       ↓
API Security
       ↓
Security Testing
       ↓
Reporting
       ↓
Web Challenges

Stage 01 — Understand Web Architecture

Before assessing an application, understand the components behind it.

A simplified architecture looks like:

User
 ↓
Browser
 ↓
DNS
 ↓
Web Server
 ↓
Application
 ↓
Database

Modern environments may also contain:

Internet
   ↓
CDN / WAF
   ↓
Load Balancer
   ↓
Web Server
   ↓
Application
   ↓
API
   ↓
Database
   ↓
Cloud Services

Each component introduces different security considerations.

Stage 02 — Understand URLs

Consider:

https://shop.example.com:443/account/profile?id=123

Break this into components:

https                 → Scheme

shop.example.com      → Host

443                   → Port

/account/profile      → Path

id=123                → Query parameter

When investigating applications, URLs reveal important information about application structure and functionality.

Stage 03 — HTTP Fundamentals

HTTP is the communication protocol behind most web applications.

A browser sends a request.

The server returns a response.

Client
  |
  | HTTP Request
  ↓
Server
  |
  | HTTP Response
  ↓
Client

Understanding this exchange is fundamental to web security.

Stage 04 — HTTP Methods

Become familiar with methods such as:

GET
POST
PUT
PATCH
DELETE
HEAD
OPTIONS

Their meaning depends on application design, but generally:

Method	Typical Purpose
GET	Retrieve information
POST	Submit/create information
PUT	Replace/update resource
PATCH	Partially update resource
DELETE	Remove resource
OPTIONS	Identify supported operations

Do not assume an operation is secure simply because the application interface does not expose it.

Stage 05 — HTTP Requests

A request can contain:

Method

Path

Headers

Cookies

Parameters

Body

Conceptually:

POST /login

Host: application.example
Content-Type: application/x-www-form-urlencoded

username=user
password=********

During authorized lab exercises, learn to identify which parts of a request are controlled by the user.

Stage 06 — HTTP Responses

Responses contain information such as:

Status Code

Headers

Cookies

Content

Error Messages

Important status-code families include:

2xx → Successful request

3xx → Redirection

4xx → Client-side/request error

5xx → Server-side error

Become familiar with common examples:

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

These responses often provide clues about application behavior.

Stage 07 — Headers

Headers carry metadata between clients and servers.

Learn to recognize headers related to:

• content types

• authentication

• cookies

• caching

• origins

• redirects

• security policies

Security testing requires understanding what these headers control rather than simply checking whether a header exists.

Stage 08 — Cookies

Cookies allow applications to maintain information between requests.

They may be used for:

• session identifiers

• preferences

• authentication state

• tracking

• application state

Understand important cookie security concepts such as:

Secure

HttpOnly

SameSite

Expiration

Scope

Sensitive session cookies require appropriate protection.

Stage 09 — Sessions

HTTP itself is largely stateless.

Applications therefore need mechanisms to remember authenticated users.

Conceptually:

User Logs In
     ↓
Credentials Validated
     ↓
Session Created
     ↓
Session Identifier Issued
     ↓
Browser Sends Identifier
     ↓
Application Recognizes User

If session management is insecure, authentication security may also fail.

Stage 10 — Application Mapping

Before testing vulnerabilities, map the application.

Identify:

• pages

• directories

• functions

• parameters

• forms

• APIs

• authentication points

• user roles

• file uploads

• administrative functions

Build a simple application map:

Application
│
├── /
├── /login
├── /register
├── /profile
├── /products
├── /orders
├── /api
└── /admin

The exact structure will vary.

The objective is to understand the application’s attack surface.

Stage 11 — Identify Inputs

User-controlled input may enter an application through many locations.

Examples include:

URL Parameters

Forms

HTTP Headers

Cookies

JSON

API Parameters

Uploaded Files

Think:

Where does external data enter the application, and what does the application do with it?

This question is fundamental to web security.

Stage 12 — Authentication Security

Authentication answers:

Who are you?

Study authentication mechanisms such as:

• username/password

• MFA

• password reset

• account recovery

• tokens

• SSO

Review the Entire Authentication Lifecycle

Registration
     ↓
Login
     ↓
Authentication
     ↓
Session
     ↓
Password Change
     ↓
Password Recovery
     ↓
Logout

A strong login page does not compensate for an insecure password-recovery process.

Stage 13 — Authorization and Access Control

Authorization answers:

What are you allowed to do?

Consider two users:

User A
User B

User A may be allowed to access:

/account/1001

while User B accesses:

/account/1002

The server must enforce these boundaries.

Never rely solely on hidden buttons or client-side restrictions.

Stage 14 — Horizontal and Vertical Access

Understand two important concepts.

Horizontal Access

A user attempts to access resources belonging to another user at the same privilege level.

User A → User B's Resource

Vertical Access

A lower-privileged user attempts to access higher-privileged functionality.

Standard User
      ↓
Administrative Function

These concepts are central to access-control testing.

Stage 15 — Input Validation

Applications constantly process untrusted data.

Secure applications should handle that data appropriately.

Potentially sensitive input locations include:

Search Fields

Login Forms

Profile Fields

URLs

API Parameters

File Uploads

Headers

Cookies

Poor input handling can create multiple classes of vulnerabilities.

Stage 16 — OWASP Security Concepts

Use the OWASP Top 10 as an important awareness framework rather than a checklist that guarantees an application is secure.

Develop familiarity with areas such as:

• broken access control

• cryptographic failures

• injection

• insecure design

• security misconfiguration

• vulnerable components

• authentication failures

• integrity failures

• logging and monitoring failures

• server-side request forgery

Your goal should be to understand why these weaknesses occur.

Stage 17 — Injection Concepts

Injection vulnerabilities occur when untrusted input is interpreted as part of a command, query or instruction rather than simply as data.

Conceptually:

User Input
    ↓
Application
    ↓
Interpreter
    ↓
Unexpected Behavior

Possible interpreters include:

• databases

• operating-system commands

• template engines

• directory services

Practice these concepts only in intentionally vulnerable lab applications.

Stage 18 — SQL Injection Fundamentals

Applications frequently communicate with databases.

Conceptually:

Browser
   ↓
Web Application
   ↓
Database Query
   ↓
Database

If application input is improperly incorporated into database queries, SQL injection may become possible.

Focus on understanding:

• where database input originates

• why unsafe query construction is dangerous

• parameterized queries

• least-privileged database accounts

• secure error handling

Understanding remediation is as important as recognizing the weakness.

Stage 19 — Cross-Site Scripting

Cross-Site Scripting occurs when untrusted content is handled in a way that allows unintended script execution in a user’s browser.

Learn the conceptual differences between:

Stored XSS

Reflected XSS

DOM-Based XSS

Understand defenses including:

• contextual output encoding

• safe DOM APIs

• input handling

• Content Security Policy as defense-in-depth

Stage 20 — File Upload Security

File-upload functionality introduces additional risk.

Consider:

What file types are accepted?

How is file content validated?

Where are files stored?

Can uploaded content execute?

Can files overwrite existing content?

Can other users access them?

Secure upload design should include multiple layers of validation and isolation.

Stage 21 — Path and File Access

Applications sometimes use user-controlled values when accessing files.

This can create security issues if file access boundaries are not properly enforced.

Think in terms of:

User Input
     ↓
Application
     ↓
File Selection
     ↓
Authorization / Validation
     ↓
File Access

The application must ensure users cannot escape their intended access boundaries.

Stage 22 — Server-Side Request Concepts

Some applications retrieve resources on behalf of users.

Conceptually:

User
 ↓
Web Application
 ↓
Requested Destination

This functionality requires careful security controls because the application server may have network access that external users do not.

Learn the concepts behind Server-Side Request Forgery (SSRF) and why destination validation and network restrictions matter.

Stage 23 — Security Misconfiguration

Not every vulnerability requires sophisticated application logic.

Common security problems may involve:

• default settings

• unnecessary services

• verbose errors

• exposed administration interfaces

• debugging functionality

• directory listings

• insecure headers

• excessive permissions

• exposed secrets

Configuration review should therefore be part of your methodology.

Stage 24 — API Security Fundamentals

Modern applications rely heavily on APIs.

A typical architecture may look like:

Browser / Mobile App
        ↓
       API
        ↓
Application Services
        ↓
Database

Learn:

• REST concepts

• endpoints

• HTTP methods

• JSON

• authentication tokens

• object identifiers

• authorization

• rate limiting

Stage 25 — API Authorization

One of the most important API questions is:

Is the server verifying that this user is allowed to access this specific object or function?

Never assume that possession of a valid token automatically means access to every resource is legitimate.

Authorization should be enforced server-side for each relevant operation.

Stage 26 — Browser Developer Tools

Your browser is already a powerful application-analysis tool.

Become comfortable using developer tools to inspect:

• requests

• responses

• headers

• cookies

• storage

• JavaScript

• network activity

This helps you understand what the application is actually doing.

Stage 27 — Web Proxy Fundamentals

During authorized labs, an intercepting web proxy can help you understand communication between the browser and application.

Conceptually:

Browser
   ↓
Testing Proxy
   ↓
Web Application

Use it to study:

• requests

• responses

• parameters

• cookies

• headers

• application behavior

The proxy is an analysis tool.

Understanding HTTP remains the underlying skill.

Stage 28 — Build a Testing Methodology

Do not randomly test vulnerability types.

Develop a repeatable workflow.

1. Confirm Authorization

2. Understand Architecture

3. Map Application

4. Identify Technologies

5. Identify Inputs

6. Understand Authentication

7. Understand Sessions

8. Identify User Roles

9. Test Access Boundaries

10. Review Input Handling

11. Review Application Logic

12. Review Configuration

13. Review APIs

14. Validate Findings

15. Collect Evidence

16. Assess Risk

17. Recommend Remediation

18. Report

Your methodology will improve with experience.

Stage 29 — Think in Trust Boundaries

One of the strongest habits you can develop is identifying trust boundaries.

Example:

Internet
   ↓
[Trust Boundary]
   ↓
Web Application
   ↓
[Trust Boundary]
   ↓
Internal API
   ↓
[Trust Boundary]
   ↓
Database

Ask:

• What crosses the boundary?

• Who controls the data?

• What validation occurs?

• What authorization occurs?

• What happens if assumptions fail?

This moves you beyond simple vulnerability hunting.

Stage 30 — Business Logic Security

Some vulnerabilities do not involve technical injection or malformed input.

The application workflow itself may be flawed.

For example:

Step 1 → Select Item
Step 2 → Calculate Price
Step 3 → Approve Transaction
Step 4 → Complete Purchase

Security questions include:

• Can steps be skipped?

• Can operations occur in the wrong order?

• Can users manipulate important values?

• Are server-side checks performed?

• Are authorization checks repeated?

Understanding business logic is an important advanced web-security skill.

Stage 31 — Evidence Collection

When you identify a potential issue, record enough evidence to demonstrate it clearly.

Capture:

Affected URL

Affected Parameter

User Role

Relevant Request

Relevant Response

Observed Behavior

Expected Behavior

Security Impact

Avoid collecting unnecessary sensitive information.

Stage 32 — Writing a Web Security Finding

Use a professional structure.

Finding Title:

Severity:

Affected Application:

Affected Endpoint:

Affected Parameter:

Description:

Prerequisites:

Evidence:

Security Impact:

Root Cause:

Recommended Remediation:

Retest Result:

A good report explains the issue to both technical and security teams.

Stage 33 — Think Like Both Attacker and Defender

For every vulnerability you practise, answer four questions:

How does it happen?

How could it be identified?

What is the impact?

How should it be fixed?

Then add a fifth:

How could defenders detect abuse?

This connects offensive security with SOC and application-security skills.

Web Security Practice Worksheet

Use this for meaningful TryHackMe exercises:

Application:

Authorization:

Objective:

Technology:

Authentication:

User Roles:

Important Endpoints:

Parameters:

Cookies / Tokens:

API Endpoints:

Potential Findings:

Validated Findings:

Affected Function:

Evidence:

Security Impact:

Root Cause:

Recommended Remediation:

Lessons Learned:

Web Security Skills Checklist

Before moving forward, evaluate yourself.

HTTP

• I understand HTTP requests

• I understand HTTP responses

• I understand HTTP methods

• I understand status codes

• I understand headers

Sessions

• I understand cookies

• I understand sessions

• I understand session identifiers

• I understand basic session-security concepts

Application Mapping

• I can map application functionality

• I can identify user-controlled inputs

• I can identify important endpoints

• I can identify user roles

Authentication

• I understand authentication workflows

• I understand password-recovery risk

• I understand MFA concepts

• I understand authentication versus authorization

Access Control

• I understand horizontal access

• I understand vertical access

• I understand server-side authorization

• I understand object-level access control

Vulnerabilities

• I understand injection concepts

• I understand XSS concepts

• I understand file-upload risk

• I understand SSRF concepts

• I understand security misconfiguration

• I understand business-logic weaknesses

APIs

• I understand API endpoints

• I understand JSON

• I understand API authentication

• I understand API authorization

• I understand object-level access concepts

Reporting

• I can document evidence

• I can explain security impact

• I can identify likely root cause

• I can recommend remediation

Challenge Progression

As your skills improve, reduce your dependency on walkthroughs.

Progress through:

Guided Exercise
      ↓
Exercise With Hints
      ↓
Documentation Research
      ↓
Independent Challenge
      ↓
Full Application Assessment

Do not measure progress only by how many rooms you complete.

Measure whether you can independently understand and assess an unfamiliar application.

From TryHackMe to GoHackersCloud Labs

Use TryHackMe for focused practice.

Then move into broader application assessments.

Web Fundamentals
       ↓
TryHackMe Practice
       ↓
Web Security Challenges
       ↓
GoHackersCloud Web Labs
       ↓
Web Pentesting Runbooks
       ↓
Application Assessment
       ↓
Professional Reporting

The objective is to gradually move from guided exercises toward independent assessment methodology.

What’s Next?

➡️ 05 Active Directory Practice

Next, we move from standalone Linux, Windows and web environments into one of the most important technologies used across enterprise networks:

Microsoft Active Directory

You will build practical understanding of:

• domains

• domain controllers

• users and groups

• organizational units

• authentication

• Kerberos

• NTLM

• permissions

• Group Policy

• service accounts

• enterprise identity

• Active Directory attack paths

• defensive visibility

• remediation

This is where your Windows, networking, authentication and ethical-hacking knowledge begins coming together inside an enterprise environment.