GopherForgeA WORKBENCH FOR GO

Senior · Go service security

A public URL redirects into an internal service

An outbound-fetch endpoint checks https and an allowed initial hostname, then follows redirects and resolves DNS again. What remains unsafe?

Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.

EXAMPLE · FRAGMENT UNLESS A COMPLETE PROGRAM IS SHOWN

go
package main

import (
	"fmt"
	"net/url"
)

func profileURL(id string) string {
	base := url.URL{Scheme: "https", Host: "api.vendor.example", Path: "/profiles"}
	q := url.Values{}
	q.Set("id", id)
	base.RawQuery = q.Encode()
	return base.String()
}
func main() {
	fmt.Println(profileURL("http://127.0.0.1/admin"))
	// The untrusted value is an encoded query value, never the destination host.
}
Reveal a strong answer

  1. A URL supplied by a user can target internal services, metadata endpoints or a different host after redirection. Checking that the string begins with https is insufficient. Prefer a small configured set of upstream services and let user input select a resource within one of them. When arbitrary destinations are a real requirement, enforce address and egress policy at connection time as well as during URL parsing.

  2. Use an owned http.Client with explicit time and response-size budgets. Disable automatic redirects or revalidate every hop under the same policy. Consider userinfo, ports, IP literals, IPv6, alternate encodings and DNS resolution/rebinding. A reviewed dialer or infrastructure egress control must enforce forbidden internal ranges against the actual connection target; validating a hostname once before a later independent DNS lookup is not enough. The attacker-shaped string stays inside a query parameter on the configured example domain. The code does not send a request and does not claim the upstream application is safe from injection. Its narrower guarantee is that this input cannot select the network host or scheme.

  3. A domain allowlist does not protect a compromised allowed service from returning hostile data, and a URL parser does not establish permission. Do not follow a redirect into a forbidden host or log upstream credentials in the URL. Test fixed-destination behavior, hostile resource IDs, redirects, private addresses, changed DNS answers and decompressed response limits in an isolated native environment.

Common trap

Parsing a URL and seeing https does not prove that the eventual network peer is allowed.

Try it

Explain fixed destinations, per-hop validation, DNS rebinding, actual dial targets, response limits and credential leakage.

Worked solution

The initial URL check is insufficient. Prefer configured destinations with user data encoded only as resource/query values. Revalidate or disallow redirects and enforce forbidden network ranges against the actual connection under a reviewed dial/egress policy. Independent DNS lookups can invalidate an earlier check. Bound operation time and decompressed body size and avoid leaking credentials from URLs or forwarding authentication to an unintended host.

Change the constraint

How do IPv6, alternate ports and proxy routing change the enforcement point?

How did you do?

Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.

Not marked. Progress stays on this browser, separate from course completion.

Primary references

Checked 2026-10-28. Use documentation for your pinned runtime, driver and tool version.