Any API endpoint that fetches a URL on the caller's behalf — a webhook validator that pings a callback URL, an avatar importer that downloads an image from a link, a PDF generator that renders a remote page — is making an outbound network request from inside the trusted network the caller cannot otherwise reach. If the caller controls which URL that request targets, they control where a trusted, internally-positioned server sends a request, and that server can usually reach places the caller's own browser never could: internal admin panels with no authentication because they were never meant to be internet-facing, databases listening only on a private subnet, and the cloud provider's own instance-metadata service.
That last target is the reason egress control matters as much as it does. Every major cloud provider exposes an instance-metadata endpoint at a fixed link-local address reachable only from inside the instance itself, and that endpoint can return temporary credentials for whatever role the instance runs as. An API backend with an unrestricted URL-fetching feature and no egress control is, from an attacker's position, a single request away from asking the server to fetch its own cloud credentials and hand them back in the response — turning a feature that looks like "download this image" into a path to the account that runs the entire deployment.
Analogy🏏Cricket
🏏 Think of it like cricket: A stadium's own operations vehicle — the one with an all-access pass sticker that lets it drive anywhere inside the venue, from the outer car park through to the pitch-side access tunnel — is normally driven only by ground staff running errands the public would never be authorised for. Now imagine a rule change where any spectator could hand a driver a destination written on a slip of paper and the driver would take the vehicle there without question, no matter what was written. A spectator cannot walk into the pitch-side tunnel themselves — security would stop them at the rope — but that same spectator could write "pitch-side tunnel" on the slip and have the all-access vehicle carry them there anyway, because the vehicle's own pass, not the passenger's identity, is what the checkpoints actually look at. The vehicle's driving privileges were designed for staff who could be trusted with the destination; letting an outside passenger dictate the destination turns the vehicle's own trusted access into the passenger's trusted access, with none of the vetting that access was supposed to require. Just as the operations vehicle can reach places a spectator's own credentials never could, an API backend's outbound requests can reach internal systems a caller's own browser never could. Just as letting any spectator write the destination on the slip hands them the vehicle's access rather than their own, letting any caller supply the URL a backend fetches hands them the backend's network position rather than their own. The insight is that server-side request forgery is not really about tricking a server into visiting a bad website — it is about a caller borrowing a trusted system's own reach to go somewhere they could never have gone on their own.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.