11 Server-Side Request & Backend Security Assessment

Mission Overview

Welcome to Lab 11 — Server-Side Request & Backend Security Assessment.

In Lab 10, you assessed how the application validates, stores, retrieves, and processes uploaded files.

Now you will focus on functionality where the server itself connects to another resource.

Modern applications frequently accept URLs or remote-resource references for features such as:

• image import

• URL previews

• remote document retrieval

• webhook configuration

• feed imports

• external API integrations

• callback URLs

• media fetching

• link metadata generation

These features create an important trust boundary.

A URL supplied by a user may look like ordinary data, but if the backend uses it to initiate a connection, the application is effectively allowing user-controlled information to influence where the server communicates.

Mission Goal: Map server-side request functionality, determine whether destinations are constrained appropriately, validate URL and redirect controls using only designated lab endpoints, and assess whether user input can influence backend communication beyond the application’s intended trust boundary.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Server-Side Request Security
Secondary Skill	Backend Trust Boundary Analysis
Environment	GoHackersCloud Web Pentesting Lab
Testing Mode	Controlled Destination Validation
Primary Outcome	Server-Side Request & Backend Security Report
Safety Level	Authorized Lab Destinations Only

Learning Objectives

By completing this lab, you will be able to:

• identify server-side request functionality

• distinguish browser requests from backend requests

• map URL-accepting parameters

• establish safe request baselines

• classify destination controls

• assess supported URL schemes

• evaluate hostname restrictions

• evaluate destination allowlisting

• observe redirect handling

• assess URL normalization

• review backend error behavior

• determine whether URL validation happens before server access

• identify server-side trust boundaries

• distinguish URL acceptance from SSRF

• validate backend request behavior without probing internal infrastructure

• document positive security controls

• assign severity and confidence

• produce a professional server-side security assessment

Core Methodology

Use:

Map → Baseline → Classify Destination → Validate URL Controls → Observe Server Behavior → Assess Boundary → Evidence → Report

Expanded:

Application Feature
       │
       ▼
Identify User-Controlled Destination
       │
       ▼
Establish Authorized Baseline
       │
       ▼
Determine Who Makes the Request
       │
       ├── Browser
       └── Application Server
       │
       ▼
Classify URL / Destination Controls
       │
       ├── Scheme
       ├── Hostname
       ├── Port
       ├── Redirect
       └── Allowlist
       │
       ▼
Use Approved Lab Destinations
       │
       ▼
Observe Backend Behavior
       │
       ▼
Validate Security Boundary
       │
       ▼
Assess Impact
       │
       ▼
Evidence & Report

The core principle is:

A user-controlled URL becomes security-sensitive when the application server acts on it.

Part 1 — Confirm Scope

Record:

ASSESSMENT ID:
GHC-WEB-LAB11-001

APPLICATION:

BASE URL:

AUTHORIZED:
Yes

TEST ACCOUNTS:

AUTHORIZED URL-BASED FEATURES:

APPROVED LAB DESTINATIONS:

EXCLUDED DESTINATIONS:

TEST WINDOW:

Your approved destinations should be dedicated training endpoints only.

Do not test real internal systems, cloud metadata services, unrelated hosts, or third-party infrastructure.

Part 2 — Create the Lab Workspace

Create:

Web-Pentesting-Labs/
└── Lab-11/
    ├── 01-Scope/
    ├── 02-Backend-Features/
    ├── 03-URL-Inputs/
    ├── 04-Baselines/
    ├── 05-Schemes/
    ├── 06-Hostnames/
    ├── 07-Ports/
    ├── 08-Redirects/
    ├── 09-Normalization/
    ├── 10-Allowlisting/
    ├── 11-Backend-Errors/
    ├── 12-Trust-Boundaries/
    ├── 13-Positive-Controls/
    ├── 14-Evidence/
    ├── 15-Findings/
    └── 16-Report/

Part 3 — Map URL-Accepting Features

Identify application functions such as:

Import Image from URL

Preview Link

Fetch Remote Document

Configure Webhook

Import RSS Feed

Retrieve Remote Metadata

External API Integration

Callback Configuration

Create:

Feature	Endpoint	Input	Purpose
Image Import	/image/import	url	Fetch image
Link Preview	/preview	url	Generate preview
Webhook	/settings/webhook	callback	Outbound notification

Part 4 — Create the Backend Feature Register

For each feature record:

FEATURE ID:

FEATURE:

ENDPOINT:

METHOD:

URL PARAMETER:

AUTHENTICATION:

EXPECTED ROLE:

SERVER-SIDE REQUEST:
Confirmed / Suspected / Unknown

EXPECTED DESTINATIONS:

BUSINESS PURPOSE:

Part 5 — Determine Who Makes the Request

This distinction is critical.

Browser-Side Request

Browser
   │
   └──────► Remote Resource

Server-Side Request

Browser
   │
   ▼
Application Server
   │
   └──────► Remote Resource

SSRF-related concerns primarily involve the second case.

Part 6 — Establish an Authorized Baseline

Use a dedicated lab-controlled destination, for example:

https://resource.training.example.test/demo

Record:

BASELINE REQUEST

Feature:

Submitted URL:

Destination:

Expected Content:

Application Response:

Fetched Successfully:
Yes / No

Server-Side Request:
Confirmed / Not Confirmed

Evidence:

Part 7 — Confirm Backend Request Behavior

Use only the training destination’s provided observation mechanism.

You may confirm:

• source is the application backend

• request timestamp

• request method

• request path

• expected user-agent or application marker

Do not configure arbitrary external callback infrastructure.

Part 8 — Build the Server-Side Request Baseline

Attribute	Result
Feature
URL
Backend request observed
Method
Destination
Redirect followed
Application output

Part 9 — Inventory URL Inputs

From Labs 04 and 08, review parameters such as:

url

uri

callback

webhook

image_url

feed_url

source

remote_file

preview_url

Do not infer SSRF merely from a parameter name.

Part 10 — Create the URL Input Register

Input ID	Endpoint	Field	Purpose
URL-001	/preview	url	Link preview
URL-002	/image/import	image_url	Remote image
URL-003	/webhook	callback	Notification

Part 11 — Classify Expected Destinations

For every feature, determine what the application should legitimately access.

Example:

Image Import:
Approved public image sources

Webhook:
Customer-owned HTTPS endpoint

Internal Integration:
Specific enterprise API only

Create:

Feature	Intended Destination Model
Image Import	Public HTTPS
Webhook	Approved HTTPS host
Internal API Connector	Fixed allowlisted host

Part 12 — Assess URL Scheme Handling

Common URL schemes include:

https

http

Applications may reject unsupported schemes.

Using only harmless lab values, determine:

Allowed

Rejected

Normalized

Unsupported

Do not test local-file, executable, or unusual protocol handlers.

Part 13 — Create the Scheme Register

Scheme	Expected	Result
HTTPS	Allowed
HTTP	Policy dependent
Unsupported benign format	Rejected

Part 14 — Evaluate HTTPS Enforcement

For security-sensitive integrations, determine whether the application requires:

https://

Record:

HTTPS POLICY

HTTPS Accepted:
Yes / No

Plain HTTP Accepted:
Yes / No

Redirected:

Security Requirement:
Known / Unknown

Plain HTTP acceptance is not automatically a critical issue, but it may matter for sensitive integrations.

Part 15 — Assess Hostname Validation

Using only preconfigured training hostnames, compare:

allowed training host

with:

unapproved training host

Record:

HOST VALIDATION

Allowed Host:

Unapproved Lab Host:

Allowed Host Result:

Unapproved Host Result:

Validation:
Effective / Weak / Unknown

Part 16 — Create the Hostname Register

Host	Classification	Result
Approved training host	Allowed
Alternate lab host	Unapproved

Part 17 — Assess Destination Allowlisting

A backend function designed for a narrow integration may use an allowlist.

Conceptually:

User URL
   │
   ▼
Normalize
   │
   ▼
Check Destination
   │
   ├── Approved → Fetch
   │
   └── Denied   → Reject

Record whether controls appear to be based on:

• hostname

• domain

• scheme

• path

• port

• complete destination

Part 18 — Create the Allowlist Profile

ALLOWLIST PROFILE

Feature:

Allowlist Present:
Yes / No / Unknown

Scheme Restricted:

Hostname Restricted:

Port Restricted:

Path Restricted:

Redirect Destination Rechecked:
Yes / No / Unknown

Part 19 — Assess Hostname Matching Carefully

A robust validation process should understand actual hostname boundaries rather than relying on superficial text matching.

In this lab, use only instructor-provided safe hostname variants.

Record whether:

exact approved host

and:

look-alike lab host

are treated differently.

Do not register or use third-party domains.

Part 20 — Assess Port Handling

Where the lab feature explicitly permits port specification, determine whether arbitrary ports are allowed.

Use only approved training services.

Record:

PORT VALIDATION

Default Port:

Alternative Approved Lab Port:

Unexpected Lab Port:

Result:

Do not probe internal or unrelated services.

Part 21 — Create the Port Register

Destination	Port	Result
Approved HTTPS service	443
Approved lab alternate	Lab-defined

Part 22 — Assess URL Normalization

Different textual URLs can identify the same logical destination.

Applications should apply destination security controls to a normalized representation.

Assess benign differences such as:

uppercase/lowercase hostname

trailing slash

default port notation

path normalization

using only approved lab endpoints.

Part 23 — Create the Normalization Register

Variant	Expected Destination	Result
Host case variation	Same
Trailing slash	Same
Default port notation	Same

Part 24 — Assess Redirect Behavior

A permitted URL may redirect elsewhere.

Conceptually:

Application
     │
     ▼
Approved URL
     │
     ▼
HTTP Redirect
     │
     ▼
New Destination

Security controls should consider the destination after redirection.

Part 25 — Use Only Approved Redirect Targets

Use a dedicated training redirect flow such as:

approved.training.example.test/redirect
               │
               ▼
resource.training.example.test/final

Both endpoints must be explicitly part of the lab.

Part 26 — Create the Redirect Register

REDIRECT TEST

Initial URL:

Initial Host:

Redirect Status:

Final Destination:

Redirect Followed:
Yes / No

Final Destination Validated:
Yes / No / Unknown

Result:

Part 27 — Assess Redirect Revalidation

If the application validates only the initial destination and then blindly follows redirects, its effective destination controls may be weaker than expected.

Document this only using the authorized lab redirect chain.

Part 28 — Assess Redirect Limits

Record whether the application:

follows one redirect

follows multiple redirects

rejects redirect loops

limits total redirects

Do not create resource-intensive redirect loops.

Part 29 — Assess URL Parsing Errors

Use benign malformed URLs, such as:

missing scheme

invalid training hostname format

empty hostname

Observe whether errors are handled safely.

Part 30 — Create the URL Error Register

Input	Result	Sensitive Detail
Missing scheme
Invalid host format
Empty URL

Part 31 — Review Backend Error Messages

Server-side request functionality may expose:

• resolver errors

• connection errors

• timeout messages

• backend library details

• internal exception information

Record:

BACKEND ERROR PROFILE

Input:

Application Error:

Host Information Exposed:

Network Information Exposed:

Framework Details:

Stack Trace:

Sensitive:
Yes / No

Part 32 — Distinguish Error Details from SSRF

Always remember:

Connection Error
      ≠
SSRF

and:

Hostname Resolution Error
      ≠
Internal Access

The application must actually perform a security-relevant server-side request outside its intended boundary for a stronger finding.

Part 33 — Assess Response Content Exposure

Some features may return:

full remote content

metadata only

image data

page title

status only

Record:

RESPONSE EXPOSURE

Remote Data Returned:

Content Type:

Response Truncated:

Metadata Only:

Raw Response Exposed:

More remote content returned may increase impact if destination controls fail.

Part 34 — Assess Authentication and Role Requirements

Not every user should necessarily configure backend integrations.

Build:

Feature	Anonymous	User	Admin
Public Preview	Policy
Webhook Config	No	User/Admin
Internal Connector	No	No	Admin

Authorization remains relevant even when the destination validation is secure.

Part 35 — Assess Saved Backend Integrations

Some URLs are stored and later executed.

Example:

Save Webhook
      │
      ▼
Later Application Event
      │
      ▼
Server Sends Request

Record:

STORED DESTINATION PROFILE

Feature:

URL Stored:

Validation at Save Time:

Validation at Execution Time:
Known / Unknown

User Can Modify:

Role:

Part 36 — Validation Should Persist Across Time

If a URL is validated only when initially stored, application behavior may change later.

A secure design should consider destination validation each time the backend makes the request.

For this lab, document the observed architecture rather than attempting DNS manipulation or external infrastructure changes.

Part 37 — Assess Content-Type Expectations

For features such as image import, the backend may expect:

image content

rather than arbitrary remote content.

Using approved lab resources, compare:

valid training image

and:

benign training text response

Record whether inappropriate content is rejected.

Part 38 — Create the Remote Content Register

Feature	Expected Content	Returned Content	Result
Image Import	Image	Image
Image Import	Image	Text

Part 39 — Assess Response Size Controls

Remote resources can be large.

Use only intentionally small training resources.

Document whether the application appears to enforce reasonable response limits.

Do not attempt resource exhaustion.

Part 40 — Assess Request Timeout Controls

Use only a lab-provided delayed endpoint if available.

Record:

TIMEOUT PROFILE

Expected Timeout:

Delayed Lab Endpoint:

Application Timeout:

User-Facing Result:

Backend Remained Stable:
Yes / No

Do not create long-running connections.

Part 41 — Assess Backend Request Method

Determine whether the server uses:

GET

POST

HEAD

for the intended workflow.

Record:

BACKEND REQUEST

Method:

Headers:

Request Body:
None / Expected Training Data

Credentials Included:
None / Application-Specific / Unknown

Do not attempt to capture or redirect secrets outside the approved lab endpoint.

Part 42 — Review Backend Credentials Carefully

Backend integrations may use API tokens or service credentials.

The security question is whether those credentials are scoped and sent only to intended destinations.

In this lab:

• do not exfiltrate credentials

• do not redirect requests to capture secrets

• do not access unrelated services

Record architecture only.

Part 43 — Build the Backend Trust Boundary Map

Example:

                         Internet / External
                                │
                                │
                   Approved Destination
                                ▲
                                │
User ─────► Web Application ────┤
                │               │
                │        Destination Validation
                │
                ▼
        Protected Backend Zone

The destination validation layer should prevent user-controlled requests from crossing unintended boundaries.

Part 44 — Classify Backend Destination Zones

Conceptually:

Approved External Service

Approved Partner Service

Application-Owned Public Service

Protected Backend Service

Administrative Service

Local Host Resources

In this lab, only access the explicitly approved training zone.

The remaining zones are mapped conceptually and treated as prohibited destinations.

Part 45 — Create the Trust Boundary Register

Zone	User-Controlled Access Expected	Lab Tested
Approved training service	Yes	Yes
Protected backend	No	No
Administrative resources	No	No
Local host resources	No	No

This clearly demonstrates safe test boundaries.

Part 46 — Understand SSRF Conceptually

A server-side request forgery condition can arise when:

User-Controlled Destination
          │
          ▼
Application Server
          │
          ▼
Unintended Destination

The key elements are:

1. the server makes the request

2. the destination is influenced by untrusted input

3. intended destination controls can be bypassed

4. the server reaches something outside the permitted trust boundary

Part 47 — Do Not Probe Protected Networks

For this course lab, you do not need to attempt access to:

localhost

private address space

link-local services

cloud instance metadata

container control endpoints

internal administrative services

Use lab-provided safe destinations that emulate the security-control behavior.

This teaches the methodology without turning the exercise into infrastructure exploitation.

Part 48 — Safe SSRF Validation Model

A safe lab can provide:

Approved Public Training Endpoint

Denied Training Endpoint

Simulated Protected Destination

The application can then demonstrate:

Approved → Allowed

Unapproved → Rejected

Simulated Protected → Rejected

without exposing any real protected infrastructure.

Part 49 — Create the Destination Validation Matrix

Destination	Intended Policy	Result
Approved training host	Allow
Alternate unapproved lab host	Deny
Simulated protected lab destination	Deny
Redirect to allowed destination	Policy
Redirect to denied lab destination	Deny

Part 50 — Identify Positive Security Controls

Examples include:

Strict HTTPS-only policy

Destination hostname allowlisting

Resolved-destination validation

Restricted outbound ports

Redirect destination revalidation

Response-size limits

Request timeouts

Content-type validation

No raw backend error exposure

Dedicated outbound proxy

Network egress controls

Least-privilege backend identity

Document the controls you can actually observe.

Part 51 — Create the Positive Control Register

Control	Result	Evidence
Host allowlist	Effective
Redirect revalidation	Effective
HTTPS enforcement	Effective
Timeout control	Effective

Part 52 — Defense in Depth

SSRF protection should not rely on a single application check.

Conceptually:

Input Validation
      +
URL Normalization
      +
Destination Allowlist
      +
Redirect Revalidation
      +
Network Egress Controls
      +
Least Privilege

This layered approach reduces risk if one control fails.

Part 53 — Potential Finding Categories

Possible findings include:

Unrestricted Server-Side URL Fetching

Destination Allowlist Bypass

Redirect Destination Not Revalidated

Unsupported URL Scheme Accepted

Backend Errors Expose Internal Details

Stored Destination Not Revalidated

Remote Content Type Not Validated

Server-Side Request Function Accessible to Unauthorized Role

Part 54 — Finding Example: Unrestricted Backend Destination

FINDING ID:
SSRF-001

TITLE:
Server-Side URL Fetch Function Accepts Unapproved Destinations

SEVERITY:
High
Depending on reachable trust boundary

CONFIDENCE:
High

ENDPOINT:
/preview

PARAMETER:
url

OBSERVATION:
The application server performed outbound requests to an
unapproved destination in the controlled lab environment.

VALIDATION:
A dedicated training endpoint outside the intended allowlist
received the backend request. No internal or third-party systems
were contacted.

IMPACT:
A user may be able to influence backend requests beyond the
application's intended destination scope.

LIMITATION:
Testing intentionally used only approved training endpoints.
No protected network destinations were probed.

RECOMMENDATION:
Apply strict destination allowlisting after URL parsing and
normalization and enforce complementary outbound network
restrictions.

Part 55 — Finding Example: Redirect Validation Weakness

FINDING ID:
SSRF-002

TITLE:
Backend Fetch Validates Initial URL but Not Redirect Destination

CONFIDENCE:
High

OBSERVATION:
The application accepted an approved training URL and followed
its redirect to a separate unapproved training destination.

IMPACT:
An allowed URL may potentially be used as an intermediate step
to reach destinations outside the intended policy.

VALIDATION:
Only dedicated lab-controlled redirect endpoints were used.

RECOMMENDATION:
Re-evaluate the complete destination after every redirect and
apply the same scheme, hostname, address, and policy controls to
each hop.

Part 56 — Finding Example: Backend Error Disclosure

FINDING ID:
BACKEND-001

TITLE:
Remote Fetch Errors Expose Backend Networking Details

SEVERITY:
Low / Medium

CONFIDENCE:
High

OBSERVATION:
Invalid training URLs caused detailed backend connection errors
to be returned to the client.

DISCLOSED INFORMATION:
Backend library and connection-processing details.

IMPACT:
The information may assist an attacker in understanding backend
request behavior and internal implementation.

RECOMMENDATION:
Return generic client-facing errors and retain detailed
diagnostics only in protected application logs.

Part 57 — Finding Example: Missing Remote Content Validation

FINDING ID:
BACKEND-002

TITLE:
Image Import Function Does Not Validate Retrieved Content Type

CONFIDENCE:
High

OBSERVATION:
The image-import function successfully retrieved and stored a
benign text response from an authorized training endpoint even
though the feature was intended exclusively for image content.

IMPACT:
Remote resources outside the intended content policy can enter
the application's processing pipeline.

RECOMMENDATION:
Validate the retrieved content using server-side content
inspection and allow only formats required by the feature.

Part 58 — Avoid False Findings

Do not report:

URL field exists.

as SSRF.

Do not report:

Server fetches an approved website.

as SSRF.

Do not report:

Application returns connection error.

as SSRF.

Do not report:

Redirect followed.

as a vulnerability unless destination policy is actually bypassed.

Part 59 — Build the Findings Register

Finding	Status	Severity	Confidence
Destination restriction
Scheme validation
Redirect validation
Error disclosure
Content validation
Role enforcement

Part 60 — Build the Backend Security Coverage Matrix

Area	Tested	Result
URL input inventory	Yes
Backend request confirmation	Yes
HTTPS enforcement	Yes
Host validation	Yes
Port restrictions	Yes/NA
URL normalization	Yes
Redirect handling	Yes
Redirect revalidation	Yes
Error handling	Yes
Content type	Yes/NA
Response limits	Observed/NA
Timeout	Observed/NA
Feature authorization	Yes
Stored destinations	Yes/NA

Part 61 — Create the Evidence Register

Example:

Evidence ID	Description
EV-SSRF-001	Feature and URL input
EV-SSRF-002	Approved backend request
EV-SSRF-003	Scheme validation
EV-SSRF-004	Host validation
EV-SSRF-005	URL normalization
EV-SSRF-006	Redirect behavior
EV-SSRF-007	Redirect revalidation
EV-SSRF-008	Backend error
EV-SSRF-009	Remote content validation
EV-SSRF-010	Positive destination control

Part 62 — Mission Challenge

Complete:

SERVER-SIDE REQUEST & BACKEND SECURITY ASSESSMENT

Assessment ID:

Analyst:

Date:


SCOPE

Application:

Base URL:

Authorized:
Yes / No

Approved Lab Destinations:


BACKEND FEATURES

Feature 01:

Endpoint:

URL Parameter:

Purpose:


Feature 02:

Endpoint:

URL Parameter:

Purpose:


REQUEST ORIGIN

Browser Request:
Yes / No

Server Request:
Yes / No

Evidence:


BASELINE

Approved URL:

Result:

Backend Request Observed:

Response:


SCHEMES

HTTPS:

HTTP:

Unsupported:

Result:


HOST VALIDATION

Approved Host:

Unapproved Lab Host:

Result:


PORT VALIDATION

Default Port:

Alternative:

Result:


URL NORMALIZATION

Hostname Case:

Trailing Slash:

Default Port:

Result:


REDIRECTS

Initial Host:

Final Host:

Redirect Followed:

Final Destination Revalidated:

Result:


ALLOWLIST

Present:

Scheme:

Host:

Port:

Path:


BACKEND ERRORS

Resolver Error:

Connection Error:

Timeout Error:

Technical Information Exposed:


REMOTE CONTENT

Expected Type:

Returned Type:

Validated:

Stored:


TIMEOUTS

Configured:

Observed:

Result:


AUTHORIZATION

Feature Role:

Standard User Access:

Administrative Access:

Result:


STORED DESTINATIONS

Stored URL:

Validated at Save:

Validated at Execution:

Result:


TRUST BOUNDARY

Allowed Zone:

Denied Zones:

Backend Boundary Enforced:
Yes / No / Inconclusive


POSITIVE CONTROLS

Control 01:

Control 02:

Control 03:


FINDINGS

Finding 01:

Severity:

Confidence:

Evidence:


Finding 02:

Severity:

Confidence:

Evidence:


LIMITATIONS

No internal/private systems were probed.

No cloud metadata services were accessed.

No unrelated third-party destinations were contacted.

Additional Limitation:


FINAL ASSESSMENT

Backend Request Control:
Effective / Weak / Inconclusive

Destination Validation:

Redirect Validation:

Content Validation:

Backend Error Handling:

Authorization:

Overall Backend Request Risk:

Ready for API Security Assessment:
Yes / No

What Not to Do

Do not:

Probe internal corporate systems

Request localhost resources

Scan private network ranges

Access cloud metadata services

Access container or orchestration control APIs

Probe internal administrative endpoints

Target third-party infrastructure

Create uncontrolled external callbacks

Attempt credential theft

Redirect backend credentials to another host

Attempt port scanning through the application

Use the server as a network scanner

Attempt protocol smuggling

Attempt denial of service

Create long-running backend requests

Attempt lateral movement

Continue testing after the security boundary has been proven

The professional rule is:

Validate destination-control failure using dedicated training endpoints, not by probing real protected infrastructure.

Professional Distinctions

Always distinguish:

URL Parameter
      ≠
SSRF

Server-Side Fetch
      ≠
SSRF Automatically

Connection Error
      ≠
Internal Service Access

DNS Error
      ≠
Backend Compromise

Redirect Followed
      ≠
Redirect Bypass Automatically

Unapproved URL Accepted
      ≠
Protected Network Reached Automatically

Backend Request Confirmed
      ≠
Security Boundary Bypassed

Public URL Fetching
      ≠
Internal Network Access

Hostname Allowlist
      ≠
Complete SSRF Protection Automatically

Application Validation
      ≠
Network Egress Control

Error Disclosure
      ≠
SSRF

SSRF Indicator
      ≠
Permission to Probe Infrastructure

Evidence Requirements

Capture:

• authorization and scope

• approved lab destinations

• Backend Feature Register

• URL Input Register

• backend-request baseline

• proof of server-side request origin

• expected destination model

• scheme validation

• HTTPS policy

• hostname validation

• destination allowlist profile

• port restrictions where applicable

• URL normalization

• redirect behavior

• redirect destination revalidation

• URL parsing/error behavior

• backend error profile

• response-content behavior

• feature authorization

• stored destination behavior where applicable

• content-type validation

• timeout/response limit observations

• backend request-method profile

• trust-boundary map

• Destination Validation Matrix

• positive security controls

• findings register

• coverage matrix

• evidence register

• explicit record that protected infrastructure was not probed

Mission Deliverables

Complete:

• scope confirmed

• approved destinations documented

• backend-request features mapped

• URL parameters identified

• browser/server request distinction established

• authorized baseline completed

• backend request confirmed

• expected destinations classified

• scheme handling assessed

• HTTPS policy assessed

• hostname controls assessed

• allowlisting assessed

• port controls assessed where applicable

• URL normalization reviewed

• redirect handling assessed

• redirect destination revalidation assessed

• URL error handling assessed

• backend errors reviewed

• remote response exposure documented

• feature authorization assessed

• stored destinations reviewed where applicable

• remote content type assessed

• timeout behavior reviewed where practical

• backend trust boundary mapped

• protected destinations explicitly excluded

• positive controls documented

• findings validated only with lab endpoints

• severity and confidence assigned

• limitations documented

• final Backend Security Assessment completed

Lab Report Template

# Lab 11 — Server-Side Request & Backend Security Assessment

## Executive Summary

## Mission Objective

## Authorization & Scope

## Approved Training Destinations

## Backend Feature Map

## URL Input Inventory

## Browser vs Server Request Analysis

## Server-Side Request Baseline

## Destination Model

## URL Scheme Validation

## HTTPS Enforcement

## Hostname Validation

## Destination Allowlisting

## Port Restrictions

## URL Normalization

## Redirect Handling

## Redirect Destination Revalidation

## URL Parsing & Error Handling

## Backend Error Disclosure

## Remote Content Validation

## Request Timeout & Response Limits

## Backend Request Method

## Feature Authorization

## Stored Destination Validation

## Backend Trust Boundary

## Positive Security Controls

## Findings

## Severity & Confidence

## Evidence Register

## Testing Limitations

## Recommendations

## Conclusion

Knowledge Check

Question 1 — What distinguishes an ordinary URL parameter from a server-side request risk?

The application backend must actually use user-controlled destination information to initiate a request.

Question 2 — Does a server-side request automatically mean SSRF?

No.

Many applications legitimately fetch remote resources. The security problem occurs when destination controls fail and unintended locations become reachable.

Question 3 — Why validate redirect destinations?

Because an initially approved URL may redirect the backend to a different destination.

Question 4 — Is hostname allowlisting enough by itself?

No.

A robust design may also require normalization, redirect revalidation, outbound network controls, response limits, and least privilege.

Question 5 — Why shouldn’t this lab probe private infrastructure?

Because destination-control weaknesses can be demonstrated safely using dedicated training endpoints without risking unauthorized access to real backend services.

Question 6 — Does a connection error prove an internal service exists?

No.

Errors can arise for many reasons and should not be over-interpreted.

Question 7 — Why are network egress controls valuable?

They provide a second security boundary even if application-level destination validation fails.

Question 8 — Why validate remote content type?

Because a feature intended to process one resource type should not blindly process arbitrary remote content.

Question 9 — Why assess stored destinations at execution time?

Because the destination used later should still meet current security policy when the backend request is actually made.

Question 10 — What is the central question?

“Can user-controlled destination information cause the application server to make requests outside the network locations and services it is intended to reach?”

Skills Achieved

After completing this lab, you should understand:

• server-side request identification

• browser vs backend request distinction

• URL-input mapping

• destination classification

• scheme controls

• HTTPS enforcement

• hostname validation

• destination allowlisting

• port restriction concepts

• URL normalization

• redirect validation

• backend error analysis

• remote content validation

• backend trust boundaries

• defense-in-depth for outbound requests

• safe SSRF validation methodology

• evidence-based backend security reporting

Professional Takeaway

A weak server-side request assessment looks like:

Find URL Parameter
      ↓
Try Random Destinations
      ↓
Receive an Error
      ↓
Report SSRF

A professional assessment looks like:

Map Backend Feature
       ↓
Confirm Server-Side Request
       ↓
Understand Intended Destinations
       ↓
Establish Approved Baseline
       ↓
Assess Scheme Controls
       ↓
Assess Host Controls
       ↓
Assess Port Controls
       ↓
Assess Normalization
       ↓
Assess Redirects
       ↓
Validate Destination Policy
       ↓
Map Trust Boundary
       ↓
Use Only Training Destinations
       ↓
Assess Security Impact
       ↓
Evidence
       ↓
Report

What’s Next?

➡️ Lab 12 — API Security Assessment

In the next lab, you will move from backend outbound communication to the application’s API security surface.

You will assess:

• API endpoint inventory

• authentication

• authorization

• object ownership

• HTTP methods

• request schemas

• JSON validation

• sensitive data exposure

• pagination

• filtering

• error behavior

• rate controls

• versioned endpoints

• deprecated API routes

• state-changing operations

• API security headers

• evidence and reporting

The methodology becomes:

Inventory → Authenticate → Baseline → Compare Identities → Validate Schema → Validate Object Access → Assess Data Exposure → Assess Rate Controls → Evidence → Report

The central question will be:

“Does the API consistently enforce authentication, authorization, input validation, data minimization, and abuse controls regardless of how the client sends the request?”