Ssrf Server Side in Gin (Go)

Server-side request forgery (SSRF) in a Gin application written in Go occurs when the application constructs HTTP requests based on attacker-controlled input without adequate validation or network scoping. Because Gin is a minimalistic web framework, it does not enforce any built-in safeguards for outgoing HTTP calls; the responsibility lies with the developer. An SSRF vector often appears when an endpoint accepts a URL parameter and uses a Go HTTP client to fetch that URL, for example:

httpClient := &http.Client{}
resp, err := httpClient.Get(userSuppliedURL)
if err != nil {
    c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
    return
}
defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
c.Data(http.StatusOK, "application/octet-stream", body)

If userSuppliedURL is not strictly validated and is allowed to reference internal resources, an attacker can force the server to probe internal services. In a containerized or cloud environment, this can lead to metadata service access (e.g., cloud instance metadata at 169.254.169.254), internal Kubernetes endpoints, or other sensitive backends that are not exposed publicly. The Gin route typically looks deceptively harmless, but the server-side HTTP client becomes the attack channel. MiddleBrick’s unauthenticated scan detects such endpoints by checking whether user-controlled inputs can reach internal network destinations, identifying SSRF as a high-severity finding when internal reachability is confirmed.

SSRF in Gin with Go is further exacerbated by common patterns such as using the standard net/http client without timeouts, failing to restrict hostnames or IP ranges, and not disabling protocols like file:// or gopher://. An attacker may supply a malicious URL that causes the server to interact with internal metadata services, databases via non-routable IPs, or even induce unintended interactions with other cloud APIs. Because Go’s HTTP client can follow redirects by default, an attacker may chain redirect responses to reach otherwise unreachable internal endpoints. The framework does not provide a built-in mechanism to sanitize these requests; developers must explicitly design network boundaries and validate targets before initiating outbound connections.

When scanning an API with SSRF vulnerabilities, MiddleBrick’s checks include network-based probes that attempt to reach internal IP ranges and metadata endpoints from the server’s perspective. Findings include evidence of unauthenticated reachability, missing protocol allowlists, and missing network segregation. Remediation focuses on input validation, network-level controls, and safe HTTP client configuration, ensuring that outgoing requests cannot be abused to pivot into internal infrastructure.

To remediate SSRF in Gin applications written in Go, enforce strict URL validation, use a restricted HTTP client, and avoid passing raw user input to outgoing requests. Below are concrete, safe patterns.

1. Validate and restrict target hosts

Use a whitelist of allowed hosts and reject private and internal IP ranges. For example:

func isAllowedHost(rawURL string) bool {
    u, err := url.Parse(rawURL)
    if err != nil {
        return false
    }
    // Only allow specific domains
    allowed := map[string]bool{"api.example.com": true, "data.example.com": true}
    if !allowed[u.Host] {
        return false
    }
    // Prevent localhost and private IPs
    ip := net.ParseIP(u.Hostname())
    if ip != nil {
        return false // or add specific allowed public IPs
    }
    return true
}

func safeFetch(c *gin.Context) {
    target := c.Query("url")
    if !isAllowedHost(target) {
        c.JSON(http.StatusBadRequest, gin.H{"error": "disallowed host"})
        return
    }
    // proceed with request
}

2. Configure a hardened HTTP client

Disable redirects, set timeouts, and avoid using the default transport that may accept insecure settings:

httpClient := &http.Client{
    Timeout: 5 * time.Second,
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        return http.ErrUseLastResponse // prevent redirect-based SSRF
    },
    Transport: &http.Transport{
        TLSClientConfig: &tls.Config{InsecureSkipVerify: false},
    },
}

resp, err := httpClient.Get(target)
if err != nil {
    c.JSON(http.StatusServiceUnavailable, gin.H{"error": "fetch failed"})
    return
}
defer resp.Body.Close()
body, err := io.ReadAll(resp.Body)
if err != nil {
    c.JSON(http.StatusInternalServerError, gin.H{"error": "read failed"})
    return
}
c.Data(http.StatusOK, "application/json", body)

3. Avoid file:// and other risky schemes

Explicitly block dangerous schemes and prefer HTTPS:

if u.Scheme != "https" {
    c.JSON(http.StatusBadRequest, gin.H{"error": "only https allowed"})
    return
}

By combining host allowlisting, redirect rejection, and strict timeouts, you significantly reduce the attack surface. MiddleBrick’s scans can verify that these controls are effective by checking whether the endpoint still permits internal network interactions. The dashboard and CLI can be used to track scan results over time, and the GitHub Action can enforce a minimum security score before merging changes.