Submits URL
Remember SSRF
Full name: Server-Side Request Forgery
Memory aid: Server Sends a Request for the Forger.
Protect internal endpoints and control outbound destinations.
Study area: Threats & application security · Batch 3
Relevant study for: CompTIA Security+ SY0-701 · ISC2 CISSP 2024 outline · CompTIA CySA+ · CompTIA PenTest+
Practice with exam flashcards →DevOps & Tooling / Knowledge library
Server-Side Request Forgery (SSRF)
Tricks a server into making attacker-influenced network requests
Why learn Server-Side Request Forgery (SSRF)?
Understanding it guides destination allowlists and network isolation
The problem it solves
It prevents public inputs from reaching internal or privileged endpoints
Where it came from
Server-Side Request Forgery (SSRF) is a security concept that tricks a server into making attacker-influenced network requests. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Server-Side Request Forgery (SSRF) and distinguish it from a neighboring concept.
- Choose a realistic task where Server-Side Request Forgery (SSRF) is appropriate.
- Identify a failure mode caused by misusing Server-Side Request Forgery (SSRF).
- Interpret a small design or result involving Server-Side Request Forgery (SSRF).
- Explain one tradeoff or limitation of Server-Side Request Forgery (SSRF).
Documentation and sources
- OWASP Developer Guide: Security Principles (devguide.owasp.org)
Connect the ideas
Explore next
Real World Example
SSRF Mitigation in Microservice Image Fetchers
A cloud-based digital asset management platform that allows users to import profile images via external URLs.
The business problem
The image processing service blindly follows user-provided URLs, allowing attackers to force the server to scan internal network segments, access metadata services, or interact with private APIs that are otherwise unreachable from the public internet.
How this topic solves it
Implement a strict allow-list and network-level isolation. By validating the destination against a predefined set of trusted domains and using a dedicated proxy that lacks access to internal infrastructure, the application prevents unauthorized requests to sensitive internal endpoints.
- Define a strict allow-list of permitted hostnames and protocols for image retrieval.
- Configure a dedicated, isolated egress proxy that cannot resolve or route to internal IP ranges like 127.0.0.1 or 169.254.169.254.
- Validate the user-provided URL against the allow-list before initiating any network request.
- Ensure the application service runs with least privilege, lacking network permissions to reach internal management interfaces.
The flow shows how an incoming request is validated against a security policy before reaching the external network.
Validates URL
Security Policy
Restricted Egress
Target Asset
- User → request_url → App Server
- App Server → check_validity → Allow-list
- App Server → forward_if_valid → Isolated Proxy
- Isolated Proxy → fetch_image → External Server
Expected business outcome
The application successfully fetches external assets while remaining resilient against attempts to probe internal network infrastructure or sensitive metadata services.
Limitations and checks
The primary limitation is the maintenance overhead of the allow-list; as business requirements change, the list must be updated, which may introduce friction if not automated. Check for this by monitoring blocked request logs to identify legitimate traffic being incorrectly denied.