Overview
SSRF is fundamentally a trust-boundary problem: the server can reach internal, trusted systems that external users cannot, and SSRF lets a user cross that boundary by proxy. This lesson frames SSRF in terms of trust boundaries.
Learning objectives
- Explain the trust boundary SSRF crosses.
- Describe internal vs external network reachability.
- Understand why SSRF impact can be severe.
Core concept
Networks are segmented into zones of differing trust (recall segmentation from the networking path): external users are outside, while the application server sits inside a trusted network with access to internal services — databases, admin interfaces, metadata endpoints, other microservices — that are not exposed externally. SSRF lets an attacker make the trusted server issue requests to these internal targets, effectively crossing the trust boundary by proxy. The server becomes an unwitting relay into the internal network.
How it works
Because the server is inside the trusted zone, it can reach addresses and services that external firewalls block for outside users. When an attacker controls the destination of a server-side request, they can point it at internal-only resources — internal IP ranges, localhost services, administrative endpoints, or cloud metadata (covered later) — which respond to the server as a trusted internal client. The attacker never connects to those systems directly; the server does it for them. This is why SSRF can expose internal infrastructure that was assumed safe behind network boundaries.
Practical example
An application server can reach an internal admin service at a private address that is unreachable from the internet. Through an SSRF-vulnerable URL-fetch feature, an attacker directs the server to request that private address; the internal service, seeing a request from the trusted server, responds — and its response (or its behavior) is exposed to the attacker. The network boundary that was supposed to protect the internal service is bypassed because the request originated from inside it, via the server.
Cybersecurity relevance
Framing SSRF as a trust-boundary crossing explains its severity: it can reach internal services, admin panels, metadata endpoints, and other systems shielded by network segmentation, potentially leading to sensitive data disclosure or further compromise. It is especially impactful in cloud environments (metadata services). This view also points to defenses: restrict destinations (allowlists), isolate the server's network access (network isolation), and never rely solely on the network boundary — all covered in the following lessons.
Common mistakes
- Assuming network segmentation alone protects internal services — SSRF crosses it by proxy.
- Treating the server as a trusted client for requests whose destination a user controls.
- Underestimating SSRF impact because "the user can't reach internal systems directly" — the server can.
Key takeaways
- SSRF is a trust-boundary problem: the server sits inside a trusted network and can reach internal services external users cannot.
- SSRF makes the trusted server issue requests to internal targets, crossing the boundary by proxy and exposing shielded systems.
- Its impact can be severe (internal services, admin panels, metadata); defenses restrict destinations, isolate the server's network access, and never rely on the network boundary alone.
Check your understanding
- What trust boundary does SSRF cross, and how does it do so "by proxy"?
- Why is network segmentation alone insufficient to protect internal services from SSRF?