Rule Information
Tags
gosecurityssrfnet-httpcloud-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-002 --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
Cross-file analysis: 3 files
About This Rule
Understanding the vulnerability and how it is detected
This rule detects SSRF flows where user input from HTTP request parameters reaches Go's standard library net/http client calls (http.Get, http.Post, http.Head, http.PostForm, and http.Client.Do). These are the most common HTTP client patterns in Go applications.
**SSRF via net/http is particularly common** because many Go web services implement "URL preview", "webhook registration", "avatar URL", or "external feed fetch" features using net/http without considering that users can supply internal or metadata URLs.
**Go URL parsing edge cases** that bypass naive host-string matching: - `url.Parse("http://169.254.169.254")` correctly identifies host as "169.254.169.254" but `url.Parse("http://169.254.169.254%2Flatest%2Fmeta-data")` or similar URL-encoded variants may bypass simple string comparison. - "Protocol-relative URLs: `url.Parse(\"//169.254.169.254\")` has an empty Scheme field" but Host = "169.254.169.254" — validation that only checks Scheme may miss this. - "IPv6-mapped IPv4: `http://[::ffff:169.254.169.254]` — url.Parse sets Host to" `[::ffff:169.254.169.254]`, which is equal to 169.254.169.254 when parsed as IP.
**Redirect following**: Go's http.Client follows redirects by default. An SSRF prevention check that validates the initial URL but doesn't validate redirect targets allows redirect-chain bypass: `https://attacker.com/redirect?to=http://169.254.169.254`. Override `CheckRedirect` to validate each redirect destination.
Complements GO-SSRF-001 which covers go-resty client. Together these rules cover the two most common Go HTTP client patterns.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
AWS IAM Credential Exfiltration
`http.Get("http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>")` returns temporary AWS credentials when IMDSv1 is enabled. With these credentials, attackers can access any AWS service the instance role permits.
2
Internal Network Reconnaissance
By varying IP and port in the target URL, attackers map internal services. HTTP response status codes and timing reveal which ports are open and what services respond.
3
Kubernetes API Server Access
`http.Get("https://kubernetes.default.svc/api/v1/secrets")` with a valid service account token (if mounted) reveals secrets across the namespace or cluster.
How to Fix
Recommended remediation steps
- 1Validate outbound URL hosts against a strict allowlist.
- 2After DNS resolution, verify resolved IPs are not in private ranges.
- 3Override http.Client.CheckRedirect to validate redirect destinations.
- 4Disable redirects entirely if not needed: CheckRedirect returning http.ErrUseLastResponse.
- 5Set connection timeouts to prevent slow-loris-style attacks on SSRF targets.
- 6Enable AWS IMDSv2 to require session tokens for metadata access.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
Tracks taint from HTTP framework sources to net/http package-level functions (http.Get, http.Post, http.Head, http.PostForm) and http.Client.Do method calls 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
CWE Top 25 (2024)
CWE-918 — Server-Side Request Forgery
PCI DSS v4.0
Requirement 6.2.4 — Protect against SSRF attacks
References
External resources and documentation
Similar Rules
Explore related security rules for Go
Frequently Asked Questions
Common questions about SSRF via Outbound net/http Client Calls
This rule detects SSRF flows where user input from HTTP request parameters reaches Go's
standard library net/http client calls (http.Get, http.Post, http.Head, http.PostForm,
and http.Client.Do). These are the most common HTTP client patterns in Go applications.
**SSRF via net/http is particularly common** because many Go web services implement
"URL preview", "webhook registration", "avatar URL", or "external feed fetch" features
using net/http without considering that users can supply internal or metadata URLs.
**Go URL parsing edge cases** that bypass naive host-string matching:
- `url.Parse("http://169.254.169.254")` correctly identifies host as "169.254.169.254"
but `url.Parse("http://169.254.169.254%2Flatest%2Fmeta-data")` or similar URL-encoded
variants may bypass simple string comparison.
- "Protocol-relative URLs: `url.Parse(\"//169.254.169.254\")` has an empty Scheme field"
but Host = "169.254.169.254" — validation that only checks Scheme may miss this.
- "IPv6-mapped IPv4: `http://[::ffff:169.254.169.254]` — url.Parse sets Host to"
`[::ffff:169.254.169.254]`, which is equal to 169.254.169.254 when parsed as IP.
**Redirect following**: Go's http.Client follows redirects by default. An SSRF
prevention check that validates the initial URL but doesn't validate redirect targets
allows redirect-chain bypass: `https://attacker.com/redirect?to=http://169.254.169.254`.
Override `CheckRedirect` to validate each redirect destination.
Complements GO-SSRF-001 which covers go-resty client. Together these rules cover
the two most common Go HTTP client patterns.
Use Code Pathfinder to scan your codebase: pathfinder scan --ruleset golang/GO-SSRF-002 --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 SSRF via Outbound net/http Client Calls rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.