Overview
SSRF (Server-Side Request Forgery) abuses a common application feature: making the server fetch a URL. To understand SSRF, you first need to see why and how applications make server-side requests. This lesson introduces that feature.
Learning objectives
- Explain what a server-side request is and why apps make them.
- Identify features that fetch URLs on the server.
- Recognize where user-controlled destinations create risk.
Core concept
A server-side request is when the application's server (not the browser) makes an outbound network request — for example, to fetch a URL, call another service, or retrieve a resource. Applications do this for many legitimate reasons: fetching a user-provided image URL, calling webhooks, importing data from a link, generating link previews, or integrating with other APIs.
The risk appears when the destination of that request is influenced by user input: the user can potentially make the server request a location the developer did not intend.
How it works
When a feature takes a URL from the user and has the server fetch it, the server acts on the user's behalf — from the server's network position. Because the server often sits inside a trusted network with access to internal systems the user could never reach directly, a user-controlled destination becomes dangerous: the user may direct the server to internal addresses, other services, or sensitive endpoints. The core issue is that the server's requests carry the server's network access and trust, not the user's — the setup for SSRF explored in the next lessons.
Practical example
A "fetch image from URL" feature lets a user provide a link, and the server downloads it to create a thumbnail. Normally the user supplies a public image URL. But since the server makes the request, a user could instead supply a URL pointing at an internal address the server can reach but the user cannot — turning the feature into a way to probe or access internal resources. The legitimate feature (server fetching a URL) becomes an SSRF vector because the destination is user-controlled.
Cybersecurity relevance
Server-side request features are widespread (image fetchers, webhooks, importers, previews, integrations), which makes SSRF a common and increasingly important vulnerability — especially in cloud environments. The essential insight is that a server-side request uses the server's network reach and trust, so allowing users to control the destination can expose internal systems. Recognizing which features make server-side requests with user-influenced URLs is the first step to identifying and defending against SSRF, developed through this module.
Common mistakes
- Letting users fully control the destination of a server-side request without restriction.
- Forgetting the server can reach internal systems the user cannot.
- Overlooking URL-fetching features (previews, webhooks, importers) as SSRF candidates.
Key takeaways
- A server-side request is one the application's server makes outbound (fetching URLs, calling services); many features do this legitimately.
- Risk arises when user input controls the destination, because the server's requests carry the server's network access and trust — not the user's.
- Such features (image fetchers, webhooks, importers, previews) are SSRF candidates; recognizing them is the first step to defense.
Check your understanding
- Why is it significant that a server-side request uses the server's network position rather than the user's?
- What kinds of application features commonly make user-influenced server-side requests?