SSRF occurs when an application fetches a URL controlled by the user and the server becomes the one making
the request, potentially reaching internal systems that the attacker cannot access directly.
CategoryServer-side request abuse
Common impactInternal service access
Common surfaceURL fetchers / webhooks
Risk modelTrust boundary bypass
What is this vulnerability?
SSRF happens when an application accepts a user-controlled URL and performs the request from the server side.
The attacker cannot directly access internal resources, but the vulnerable server may be able to.
How it works
A feature such as image import, webhook validation, URL preview, file download, or integration testing
may request an external URL. If the URL is not restricted, an attacker can point it to private networks,
local services, or cloud metadata endpoints.
Minimal vulnerable example
This simplified example shows a backend endpoint fetching a user-provided URL without validating the target.
Waiting to run demo…
1. User submits a URL
2. Server fetches it
3. Target points inward
4. Internal resource responds
5. Data or behavior leaks
Potential impact
Access to internal-only services, admin panels, or local endpoints.
Exposure of cloud metadata or environment-specific service information.
Port scanning or service discovery from the server’s network position.
Bypass of perimeter controls when the vulnerable server is trusted internally.
Mitigation
Use allowlists for expected domains and protocols.
Block private IP ranges, loopback addresses, link-local addresses, and metadata endpoints.
Re-resolve and validate DNS after redirects to prevent redirect-based bypasses.
Run outbound fetchers in isolated networks with strict egress controls.
Need private analysis for your codebase?Request SSRF reachability review and dependency risk mapping from FikreSekhel Research.