Overview
SSRF impact depends on what the server can reach across network boundaries — so understanding them shapes both the risk and the hunt. This lesson covers network boundaries in SSRF.
Learning objectives
- Explain network boundaries in the SSRF context.
- Describe what SSRF can reach across them.
- Connect boundaries to SSRF impact and defense.
Core concept
SSRF's power comes from the server's network position — it can reach systems across network boundaries that external users cannot (internal services, admin interfaces, cloud metadata endpoints), from the web-security SSRF module. An SSRF turns the trusted server into a proxy across these boundaries. Thus the impact of an SSRF depends on what the server can reach: an SSRF on a server with broad internal access is far more severe than one on a server that is network-isolated (egress-restricted). Understanding the boundaries clarifies both the risk and what a demonstrated SSRF could (safely) show.
How it works
When assessing a (safely-confirmed) SSRF, the researcher considers what the server can reach across boundaries: can it reach internal-only services, admin endpoints, or the cloud metadata service (which could expose credentials — a critical outcome)? This determines the SSRF's impact/severity. Crucially, in bug bounty this is assessed safely and in-scope — the researcher demonstrates the SSRF and reasons about reachable targets without actually attacking internal systems, exfiltrating data, or accessing real metadata credentials (proving the SSRF and its potential is sufficient). Network isolation (egress restriction) on the server limits SSRF impact — a key defensive factor.
Practical example
Having safely confirmed an SSRF in an in-scope fetcher, the researcher assesses impact via network boundaries: the server appears able to reach internal-only addresses (suggesting significant impact) and possibly the cloud metadata endpoint (a critical concern). They demonstrate the SSRF minimally and reason about the reachable internal targets to convey severity — without actually attacking internal systems or extracting real metadata credentials, which would be harmful and out of bounds. The boundary analysis informed an accurate, responsibly-assessed impact for the report.
Cybersecurity relevance
Network boundaries determine SSRF impact: reaching internal services or (especially) cloud metadata (potential credential exposure) makes SSRF critical, while a network-isolated server limits it — directly reflecting the web-security SSRF trust-boundary and network-isolation lessons. Understanding boundaries lets the researcher assess severity accurately and safely (reasoning about reachability without actually attacking internal systems or extracting real credentials — respecting "do no harm" and program rules). For defenders, network isolation (egress restriction, blocking metadata) is a key SSRF mitigation. Boundary understanding is essential to responsible SSRF impact assessment.
Common mistakes
- Actually attacking internal systems or extracting real metadata credentials instead of safely reasoning about reachability.
- Ignoring network boundaries when assessing SSRF impact/severity.
- Overlooking network isolation as a key SSRF mitigation for defenders.
Key takeaways
- SSRF leverages the server's network position to reach across boundaries (internal services, admin, cloud metadata) that external users can't — the server becomes a proxy.
- Impact/severity depends on what the server can reach; reaching cloud metadata (credential exposure) is critical, while network isolation limits impact.
- Assess impact safely — reason about reachable targets without actually attacking internal systems or extracting real credentials; network isolation is a key defense (reflecting web-security SSRF lessons).
Check your understanding
- Why does SSRF impact depend on what the server can reach across network boundaries?
- How does a researcher assess SSRF impact safely without attacking internal systems or extracting real credentials?