Overview
Assessing and communicating an SSRF's impact — safely — determines its severity and value. This capstone lesson covers SSRF impact and consolidates SSRF hunting.
Learning objectives
- Describe the range of SSRF impact.
- Explain assessing impact safely.
- Consolidate the SSRF-hunting module.
Core concept
SSRF impact ranges widely depending on what the server-side request can reach and do: from limited (only reaching innocuous destinations) to severe — accessing internal services, admin interfaces, or the cloud metadata service (potentially exposing credentials and enabling cloud compromise, the highest-impact case from the web-security SSRF/cloud-metadata lessons). Impact assessment combines what the server can reach (network boundaries) with what an attacker could achieve. In bug bounty, impact is assessed and demonstrated safely — proving the SSRF and reasoning about its potential without actually causing harm or accessing real sensitive data/credentials.
How it works
For a safely-confirmed SSRF, the researcher assesses impact by considering reachable targets and potential outcomes: could it expose internal service data, reach admin functions, or (critically) access cloud metadata/credentials? They demonstrate the SSRF minimally and safely — enough to prove it and convey its potential impact — without attacking internal systems, exfiltrating data, or accessing real credentials (proving existence and reachability, and reasoning about impact, is sufficient and responsible). The assessed impact (grounded in the safe demonstration, not exaggerated) drives severity and is communicated in the report. This mirrors the safe impact-assessment discipline from the exploitation-concepts module.
Practical example
Having safely confirmed an SSRF in an in-scope fetcher that appears able to reach internal addresses and the cloud metadata endpoint, the researcher assesses impact as potentially critical (possible internal access and credential exposure) — reasoning from the safe demonstration and network-boundary analysis, without actually extracting credentials or attacking internal systems. They report the SSRF with this responsibly-assessed impact and severity, plus remediation (allowlist destinations, network isolation, protect metadata). The safe impact assessment produced an accurate, high-value finding.
Cybersecurity relevance
Impact assessment determines an SSRF's severity and thus its bug bounty value, and SSRF can be critical (internal access, cloud-credential exposure). Assessing impact safely — proving the flaw and reasoning about potential without causing harm or accessing real credentials — is both responsible (per "do no harm" and program rules) and sufficient for a strong finding, echoing the exploitation-concepts safe-impact discipline. This consolidates SSRF hunting — server-side fetchers, URL validation, network boundaries, and impact — a systematic, safe approach to finding, validating, and responsibly assessing SSRF, with remediation (allowlisting, network isolation, metadata protection) from the web-security SSRF module.
Common mistakes
- Actually exploiting SSRF to extract credentials/data to "prove" impact (harmful, prohibited, unnecessary).
- Exaggerating impact beyond what the safe demonstration supports.
- Not assessing reachable targets/boundaries when determining severity.
Key takeaways
- SSRF impact ranges from limited to critical (internal services, admin interfaces, cloud metadata/credential exposure), based on reachability and potential outcomes.
- Assess impact safely — prove the SSRF and reason about its potential without attacking internal systems or accessing real credentials; ground severity in the safe demonstration.
- It consolidates SSRF hunting (fetchers, URL validation, network boundaries, impact) into a systematic, safe approach; remediation is allowlisting, network isolation, and metadata protection.
Check your understanding
- What determines whether an SSRF is low- or critical-impact?
- Why is proving the SSRF and reasoning about impact sufficient, rather than actually extracting credentials or attacking internal systems?