Choose your depth. Learn at your own pace.
Understand it
Server-side request forgery occurs when an application can be induced to send a request to an unintended destination. The important difference is who sends the request: the server may reach systems that the original user cannot.
Cedar Preview fetches a web address to produce a link preview. If it accepts any destination, its network position can become a bridge to restricted services. The visual uses symbolic destinations and makes no real network requests.
Under the hood
URL handling includes parsing, scheme checks, hostname resolution, IP ranges, ports and redirects. Checking a string prefix is not enough. A redirect can lead from an allowed-looking address to a restricted destination, and DNS answers can change between checks and connection.
When possible, select destinations from an allowlist of trusted integrations rather than accepting arbitrary URLs. If arbitrary public fetching is required, isolate the fetcher and enforce network-level egress policy in addition to application validation.
Practitioner perspective
Map the fetcher’s network access and ambient credentials. Cloud metadata and internal control planes need explicit protection, but blocking one special address is not a complete defense. Consider IPv6, alternative representations and redirects in a controlled test environment.
Observe outbound connection destinations, denied egress and unexpected protocol use. Correlate a user request with downstream fetches. A successful HTTP response is not required for impact; an unintended internal action or timing difference can matter.
Watch it work
A fictional, simplified model. Select a component to inspect it, or follow the steps in order.
Explore the system
User URL
A request supplies an unintended internal destination.
Read every step without animation
Unrestricted fetch
- User URL. A request supplies an unintended internal destination.
- Preview server. The server accepts the destination without adequate policy.
- Internal service. The server’s network access reaches a restricted boundary.
The server becomes a bridge across the intended network boundary.
Restricted fetch
- User URL. The same destination is requested.
- Destination policy. The fetcher rejects disallowed destinations and redirects.
- Egress boundary. Network policy independently limits reachable services.
Application and network controls constrain the fetch.
Attack view
The user chooses a destination that the server should not contact. The server’s privileges and connectivity make the same destination more consequential than an ordinary browser link.
Defender view
- Constrain destinations, schemes, ports and redirect behavior.
- Apply egress restrictions and isolate public-content fetchers.
- Remove unnecessary credentials and access from the fetching component.
Common mistakes
- Allowing only https does not prove a destination is safe.
- Blocking a single metadata address is not complete SSRF prevention.
Check your understanding
Active recall: explain this idea in 30 seconds
Server-side request forgery occurs when an application can be induced to send a request to an unintended destination. The important difference is who sends the request: the server may reach systems that the original user cannot.
Now give an example and name one limitation. Revisit the explanation if you get stuck.
Primary sources
Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.
Content reviewed 2026-09-10. Read the editorial policy.