VenedyPer the OWASP page: Exploitability "Easy", Prevalence "Common", Detectability "Easy", Technical Impact "Moderate", Business Impact "Specific". Note: Basic SSRF (the response is returned to the attacker) is easier to exploit than Blind SSRF, where the attacker gets no feedback about success.
How the Attack Works
Many modern API features are meant to fetch external resources whose address the client specifies - for example when uploading a profile picture by URL, with webhooks, URL previews, or single sign-on.
If proper validation of this user-supplied URI is missing, the attacker can specify an internal target instead of a harmless external address (e.g. localhost, internal IP ranges, or cloud metadata endpoints). The server then executes the request with its own network privileges and thereby reaches systems that are not accessible from outside.
- Basic SSRF: the response is returned to the attacker (easy to exploit).
- Blind SSRF: the attacker gets no direct feedback and has to infer indirectly (e.g. via response times) whether a port is open.
Cloud, Kubernetes, and Docker environments make this easier, since they provide management and control channels over HTTP on predictable, well-known paths.
According to OWASP, the SSRF risk cannot always be fully eliminated; the business risks and needs should be taken into account when choosing a protection measure.
The API is abused to request internal targets.
Example
POST /graphql
[
{
"variables": {},
"query": "mutation { createNotificationChannel(input: { channelName: \"ch_piney\", notificationChannelConfig: { customWebhookChannelConfigs: [ { url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", send_test_req: true } ] } }) { channelId } }"
}
]Impact
Successful exploitation can lead to enumeration of internal services (e.g. port scanning), information disclosure, bypassing of firewalls, or other security mechanisms.
In some cases, a denial of service can be triggered, or the server is abused as a proxy to conceal malicious activity.
In the webhook example, the attacker can even obtain valid cloud credentials via the cloud metadata endpoint. The technical impact is rated "Moderate" by OWASP, the business impact "Specific" (context-dependent).
How to Protect Yourself
- Isolate the resource-fetching mechanism at the network level - these functions are meant to fetch external, not internal, resources.
- Use allow-lists wherever possible: for permitted remote sources (e.g. Google Drive, Gravatar), for permitted URL schemes and ports, and for accepted media types per feature.
- Disable HTTP redirects.
- Use a well-tested and well-maintained URL parser to avoid problems caused by URL-parsing inconsistencies.
- Validate and sanitize all client-supplied input data.
- Don't return raw (unmodified) responses to the client.