Rule Information
Tags
gosecurityssrfrestyhttp-clientcloud-metadataCWE-918OWASP-A10
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset golang/GO-SSRF-001 --project .1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Cross-file analysis: 3 files
About This Rule
Understanding the vulnerability and how it is detected
Server-Side Request Forgery (SSRF) occurs when an attacker can control the URL for an outbound HTTP request made by the server. The application acts as a proxy, sending requests to attacker-specified destinations that may be unreachable directly.
**go-resty** (github.com/go-resty/resty) is a popular HTTP client library for Go with a fluent API. When user-controlled input reaches resty's URL parameters (R.Get(), R.Post(), R.SetURL(), etc.) without validation, SSRF vulnerabilities arise.
**Cloud metadata endpoint attacks** (most critical impact): - "**AWS IMDSv1** (169.254.169.254): `GET /latest/meta-data/iam/security-credentials/<role>`" returns temporary AWS credentials (AccessKeyId, SecretAccessKey, Token) in JSON. These credentials have the IAM permissions of the EC2 instance role — potentially S3 read/write, RDS access, Lambda invocation, etc. IMDSv1 requires no session token and is accessible from any process on the instance, including SSRF payloads. - "**AWS IMDSv2**: Requires a PUT request first to obtain a session token, then GET" requests must include `X-aws-ec2-metadata-token`. Mitigates SSRF but is not universal — many older deployments still use IMDSv1. - "**GCP metadata**: `http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token`" returns an OAuth2 access token with the instance's service account permissions. Requires `Metadata-Flavor: Google` header — but many SSRF tools set this automatically. - "**Azure IMDS**: `http://169.254.169.254/metadata/instance?api-version=2021-02-01`" (requires `Metadata: true` header). Returns instance metadata and managed identity tokens.
**URL bypass techniques**: Naive host-string matching is bypassed by: - "Decimal IP: `http://2130706433` = 127.0.0.1" - "IPv6: `http://[::1]`, `http://[0:0:0:0:0:ffff:7f00:1]`" - "IPv6-mapped IPv4: `http://[::ffff:169.254.169.254]`" - "URL encoding: `http://169.254.169.254%2F` or `http://169.254.169%2e254`" - "DNS rebinding: hostname resolves to external IP first (passes check), then attacker's" DNS returns 169.254.169.254 before the actual HTTP request — bypasses IP allowlisting based on DNS resolution at validation time.
The correct defense is to validate URLs by resolving them first and checking the **resolved IP address** against a blocklist of private ranges, not just the URL string.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Cloud IAM Credential Theft (AWS/GCP/Azure)
SSRF to 169.254.169.254 retrieves cloud instance metadata including temporary IAM credentials. An attacker with these credentials can access AWS S3, invoke Lambda, read RDS databases, or perform any action the instance role permits — often providing full account access through privilege escalation via IAM.
2
Internal Service Enumeration
The server can probe internal IPs and ports not accessible from the internet. Responses (HTTP status codes, error messages, content length) reveal which services are running, their versions, and internal network topology.
3
Internal API Exploitation
Internal services often have weaker authentication assumptions ("only internal clients reach this"). SSRF provides access to admin APIs, monitoring endpoints, and service-to-service APIs without authentication.
4
Kubernetes Service Account Token Theft
In Kubernetes environments, SSRF to the Kubernetes API server or the metadata service can retrieve service account tokens. These tokens may have cluster-admin permissions or access to secrets across namespaces.
How to Fix
Recommended remediation steps
- 1Validate outbound URLs against an explicit allowlist of permitted hosts.
- 2After DNS resolution, verify the resolved IP is not in private ranges (10/8, 172.16/12, 192.168/16, 127/8, 169.254/16) to prevent DNS rebinding bypass.
- 3Block cloud metadata endpoints: 169.254.169.254 and metadata.google.internal.
- 4Enforce HTTPS-only for outbound requests in security-sensitive contexts.
- 5Disable HTTP redirects in the HTTP client or re-validate URLs after each redirect.
- 6Enable AWS IMDSv2 (instance metadata service v2) to require session tokens.
- 7Apply network-level egress filtering as defense-in-depth.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
Tracks taint from HTTP framework sources (gin.Context, echo.Context, fiber.Ctx, net/http.Request) to go-resty client methods (R().Get, R().Post, R().Execute, R().SetURL) with global inter-procedural scope.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
OWASP Top 10
A10:2021 — Server-Side Request Forgery (SSRF) — added as a standalone category in 2021
CWE Top 25 (2024)
CWE-918 — Server-Side Request Forgery
PCI DSS v4.0
Requirement 6.2.4 — Protect against server-side request forgery attacks
NIST SP 800-53 Rev 5
SC-7 — Boundary Protection; CA-3 — System Interconnections
References
External resources and documentation
Similar Rules
Explore related security rules for Go
HIGH
SSRF via Outbound net/http Client Calls
User-controlled input flows into net/http standard library client methods without URL validation, enabling SSRF attacks against internal services and cloud metadata endpoints.
HIGH
Open Redirect via User-Controlled URL
User-controlled input flows into HTTP redirect functions without URL validation — open redirect enables phishing, OAuth token theft, and malware distribution via trusted-domain URLs.
Frequently Asked Questions
Common questions about Server-Side Request Forgery via go-resty HTTP Client
Server-Side Request Forgery (SSRF) occurs when an attacker can control the URL for an
outbound HTTP request made by the server. The application acts as a proxy, sending
requests to attacker-specified destinations that may be unreachable directly.
**go-resty** (github.com/go-resty/resty) is a popular HTTP client library for Go with
a fluent API. When user-controlled input reaches resty's URL parameters (R.Get(), R.Post(),
R.SetURL(), etc.) without validation, SSRF vulnerabilities arise.
**Cloud metadata endpoint attacks** (most critical impact):
- "**AWS IMDSv1** (169.254.169.254): `GET /latest/meta-data/iam/security-credentials/<role>`"
returns temporary AWS credentials (AccessKeyId, SecretAccessKey, Token) in JSON.
These credentials have the IAM permissions of the EC2 instance role — potentially
S3 read/write, RDS access, Lambda invocation, etc. IMDSv1 requires no session token
and is accessible from any process on the instance, including SSRF payloads.
- "**AWS IMDSv2**: Requires a PUT request first to obtain a session token, then GET"
requests must include `X-aws-ec2-metadata-token`. Mitigates SSRF but is not universal
— many older deployments still use IMDSv1.
- "**GCP metadata**: `http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token`"
returns an OAuth2 access token with the instance's service account permissions.
Requires `Metadata-Flavor: Google` header — but many SSRF tools set this automatically.
- "**Azure IMDS**: `http://169.254.169.254/metadata/instance?api-version=2021-02-01`"
(requires `Metadata: true` header). Returns instance metadata and managed identity tokens.
**URL bypass techniques**: Naive host-string matching is bypassed by:
- "Decimal IP: `http://2130706433` = 127.0.0.1"
- "IPv6: `http://[::1]`, `http://[0:0:0:0:0:ffff:7f00:1]`"
- "IPv6-mapped IPv4: `http://[::ffff:169.254.169.254]`"
- "URL encoding: `http://169.254.169.254%2F` or `http://169.254.169%2e254`"
- "DNS rebinding: hostname resolves to external IP first (passes check), then attacker's"
DNS returns 169.254.169.254 before the actual HTTP request — bypasses IP allowlisting
based on DNS resolution at validation time.
The correct defense is to validate URLs by resolving them first and checking the
**resolved IP address** against a blocklist of private ranges, not just the URL string.
Use Code Pathfinder to scan your codebase: pathfinder scan --ruleset golang/GO-SSRF-001 --project .
This vulnerability is rated as HIGH severity.
Yes! Code Pathfinder allows you to customize rules. Modify detection patterns, adjust severity levels, add custom sanitizers, and configure the rule to fit your organization's security policies.
New feature
Get these findings posted directly on your GitHub pull requests
The Server-Side Request Forgery via go-resty HTTP Client rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.