Overview
Even with input controls, a strong SSRF defense is network isolation — limiting what the application server can reach at the network level, so a successful SSRF has little to target. This lesson covers network isolation as SSRF defense in depth.
Learning objectives
- Explain network isolation as an SSRF control.
- Describe egress filtering and segmentation for the app server.
- Understand isolation as defense in depth alongside allowlists.
Core concept
Network isolation restricts the application server's outbound (egress) network access so that, even if an attacker controls a request destination, the server cannot reach sensitive internal systems. Techniques include:
- Egress filtering — firewall rules limiting where the server may connect outbound (only required destinations).
- Segmentation — placing the server so it cannot reach internal admin services, databases, or metadata endpoints it does not need.
- Blocking access to sensitive endpoints — e.g. cloud metadata services (next lesson) at the network layer.
How it works
SSRF is only useful to an attacker if the server can actually reach valuable internal targets. By constraining the server's egress — allowing it to connect only to the specific external/internal destinations it legitimately needs, and blocking the rest — network isolation ensures that an SSRF attempt to reach an internal service simply fails at the network layer. This is defense in depth: it complements input-side allowlisting so that even if an application-layer control is bypassed, the network still contains the attack. It applies the segmentation and least-privilege principles from the networking and Linux paths to the server's network access.
Practical example
An application server that only needs to call a payment API and a couple of partner endpoints is placed behind egress rules permitting exactly those destinations and denying all other outbound traffic — including internal ranges and the cloud metadata address. If an SSRF flaw let an attacker aim the server at an internal admin service or metadata endpoint, the connection is blocked by the egress firewall, so the attack yields nothing. The application-layer allowlist and the network isolation together leave no path to sensitive targets.
Cybersecurity relevance
Network isolation is a powerful, recommended SSRF mitigation, especially in cloud and microservice environments where internal services and metadata endpoints are attractive targets. Because application-layer controls can have gaps, restricting the server's egress provides a robust backstop — SSRF is neutralized if there is nothing reachable to attack. Defenders combine egress filtering and segmentation with input allowlisting; assessments consider whether the server's network access is appropriately constrained. It embodies defense in depth for SSRF.
Common mistakes
- Allowing broad outbound access from the app server, so SSRF has many internal targets.
- Relying only on application-layer checks without network-level egress restrictions.
- Leaving sensitive endpoints (e.g. metadata) reachable from the server at the network layer.
Key takeaways
- Network isolation restricts the app server's outbound access via egress filtering and segmentation, so SSRF cannot reach sensitive internal systems.
- SSRF is only useful if the server can reach valuable targets; blocking that at the network layer neutralizes the attack even if input controls fail.
- It is defense in depth alongside destination allowlisting, applying segmentation/least-privilege to the server's network access — especially important in cloud environments.
Check your understanding
- How does restricting the server's outbound (egress) network access mitigate SSRF even if an input control is bypassed?
- Why is network isolation considered defense in depth alongside destination allowlisting?