Innomerc Learn
English is the default.
Application Security

Server-Side Request Forgery

See how a user-controlled destination can make a server cross a network trust boundary.

Intermediate6 min explorationReviewed
My learningNot started

Choose your depth. Learn at your own pace.

Simple explanation

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.

Technical explanation

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 explanation

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.

See the decision happen

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.

1 / 3
Read every step without animation

Unrestricted fetch

  1. User URL. A request supplies an unintended internal destination.
  2. Preview server. The server accepts the destination without adequate policy.
  3. Internal service. The server’s network access reaches a restricted boundary.

The server becomes a bridge across the intended network boundary.

Restricted fetch

  1. User URL. The same destination is requested.
  2. Destination policy. The fetcher rejects disallowed destinations and redirects.
  3. 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

Why is SSRF different from clicking a link in your own browser?
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.

What comes next?

Web and application security

Back to topic