Rule Information
Tags
gosecurityopen-redirectphishingoauthCWE-601OWASP-A01
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-REDIRECT-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
31
32
33
34
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
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
Cross-file analysis: 3 files
About This Rule
Understanding the vulnerability and how it is detected
Open redirect occurs when user-controlled input is used as the destination URL in an HTTP redirect (http.Redirect, gin.Context.Redirect, etc.) without validation. Attackers craft URLs pointing to the trusted domain that silently redirect users to attacker sites: `https://trusted-app.com/login?next=https://evil.com`.
**Why this matters beyond simple phishing**: - "**OAuth 2.0 token theft**: When OAuth providers validate redirect_uri using prefix" matching or insufficient validation, an open redirect on the OAuth client can be chained: `?redirect_uri=https://trusted.com/redirect?next=https://attacker.com`. The OAuth code/token flows through the trusted domain then to the attacker. - "**SSO bypass**: SAML and OAuth flows often use a `next` or `returnTo` parameter." An open redirect in the post-login flow redirects authenticated users immediately after login to attacker-controlled sites with their session active.
**URL parsing edge cases that bypass naive checks** (Go-specific): - "Protocol-relative: `//evil.com` — `url.Parse(\"//evil.com\").Host` = \"evil.com\" but" many naive checks only look for `http://` or `https://`. - `javascript:alert(1)` — Go's `url.Parse` parses scheme as "javascript". Browsers execute javascript: URLs when used in redirect headers. - "Missing scheme with valid TLD: `evil.com` — browsers interpret as relative path" to `http://evil.com` in some redirect contexts. - "Double-slash in path: `/\\\\evil.com` — some browsers normalize `\\` to `/`." - "Unicode normalization: `ℯvil.com` ≠ `evil.com` — visually similar but different hosts."
**Go's http.Redirect**: Setting the Location header without validation makes your server an open redirector. Go does not validate Location header values.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
OAuth Authorization Code Theft
If the OAuth client app has an open redirect, attackers chain it with OAuth: the authorization server sends the code to `redirect_uri=https://client.com/redirect?to=evil`, the client immediately redirects to `evil.com?code=AUTH_CODE` passing the code in the Referer header or URL. The attacker exchanges the code for a token.
2
Post-Login Phishing with Active Session
User logs in normally, but the `next` parameter sends them to a phishing page while their session is active. The attacker's page (identical to the legitimate one) asks for additional information ("confirm your 2FA code") with the user believing they are still on the trusted site.
3
Malware Distribution
Links distributed as `https://trusted.com/go?url=https://malware.example/payload` appear safe in security tools that check the initial domain. Users and security scanners may trust the trusted.com domain without following the redirect.
4
SSRF Chain
An open redirect combined with an SSRF vulnerability in a third-party service: the third-party fetches `https://trusted.com/redirect?url=http://169.254.169.254` and follows the redirect to the metadata endpoint.
How to Fix
Recommended remediation steps
- 1For post-login redirects: only allow relative paths starting with "/" but not "//".
- 2For cross-origin redirects: use an explicit allowlist of permitted full URLs.
- 3After url.Parse, verify Scheme is empty OR explicitly "https" to a known host.
- 4Never allow javascript:, data:, or protocol-relative (//host) redirect targets.
- 5Check for newlines (\r\n) in redirect targets to prevent HTTP header injection.
- 6For OAuth flows: validate redirect_uri strictly; prefix matching is insufficient.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
Tracks taint from HTTP framework sources to http.Redirect, gin.Context.Redirect, echo.Context.Redirect, and fiber.Ctx.Redirect calls with global inter-procedural scope.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
OWASP Top 10
A01:2021 — Broken Access Control (open redirect is a broken access control violation)
CWE Top 25 (2024)
CWE-601 — URL Redirection to Untrusted Site
PCI DSS v4.0
Requirement 6.2.4 — Protect against unvalidated redirects
References
External resources and documentation
Similar Rules
Explore related security rules for Go
HIGH
Server-Side Request Forgery via go-resty HTTP Client
User-controlled input flows into go-resty HTTP client calls without URL validation, enabling SSRF attacks that steal cloud metadata credentials or probe internal services.
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.
Frequently Asked Questions
Common questions about Open Redirect via User-Controlled URL
Open redirect occurs when user-controlled input is used as the destination URL in an
HTTP redirect (http.Redirect, gin.Context.Redirect, etc.) without validation. Attackers
craft URLs pointing to the trusted domain that silently redirect users to attacker sites:
`https://trusted-app.com/login?next=https://evil.com`.
**Why this matters beyond simple phishing**:
- "**OAuth 2.0 token theft**: When OAuth providers validate redirect_uri using prefix"
matching or insufficient validation, an open redirect on the OAuth client can be
chained: `?redirect_uri=https://trusted.com/redirect?next=https://attacker.com`.
The OAuth code/token flows through the trusted domain then to the attacker.
- "**SSO bypass**: SAML and OAuth flows often use a `next` or `returnTo` parameter."
An open redirect in the post-login flow redirects authenticated users immediately
after login to attacker-controlled sites with their session active.
**URL parsing edge cases that bypass naive checks** (Go-specific):
- "Protocol-relative: `//evil.com` — `url.Parse(\"//evil.com\").Host` = \"evil.com\" but"
many naive checks only look for `http://` or `https://`.
- `javascript:alert(1)` — Go's `url.Parse` parses scheme as "javascript". Browsers
execute javascript: URLs when used in redirect headers.
- "Missing scheme with valid TLD: `evil.com` — browsers interpret as relative path"
to `http://evil.com` in some redirect contexts.
- "Double-slash in path: `/\\\\evil.com` — some browsers normalize `\\` to `/`."
- "Unicode normalization: `ℯvil.com` ≠ `evil.com` — visually similar but different hosts."
**Go's http.Redirect**: Setting the Location header without validation makes your
server an open redirector. Go does not validate Location header values.
Use Code Pathfinder to scan your codebase: pathfinder scan --ruleset golang/GO-REDIRECT-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 Open Redirect via User-Controlled URL rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.