Ssrf in Chi with Api Keys

Server-Side Request Forgery (SSRF) in Chinese applications that rely on API keys creates a risk pattern where an attacker can force the server to make requests to internal or restricted endpoints using trusted credentials. In Chi, common backend stacks such as Gin or Echo often load API keys from configuration or environment variables and pass them to outbound HTTP clients. If user-controlled URLs are used directly in HTTP requests, an attacker can supply an internal address like http://169.254.169.254 (IMDS on cloud providers) or a Kubernetes service IP, causing the server to send outbound requests with the embedded API key. This can expose sensitive metadata or allow traversal to internal services that would otherwise be unreachable. middleBrick detects SSRF as one of its 12 parallel security checks and highlights how API key handling in outbound paths may amplify impact.

For example, a Chi HTTP handler that builds a request using a user-supplied URL and a static API key can inadvertently enable SSRF:

package main

import (
    "net/http"
    "os"
)

func main() {
    http.HandleFunc("/forward", func(w http.ResponseWriter, r *http.Request) {
        target := r.URL.Query().Get("url")
        apiKey := os.Getenv("API_KEY")
        req, _ := http.NewRequest(r.Method, target, r.Body)
        req.Header.Set("Authorization", "Bearer "+apiKey)
        client := &http.Client{}
        resp, _ := client.Do(req)
        defer resp.Body.Close()
        w.WriteHeader(resp.StatusCode)
    })
}

If target is not validated, an attacker can set url to an internal endpoint, and the outbound request will carry the API key, potentially accessing metadata or internal APIs. middleBrick’s OpenAPI/Swagger analysis can cross-reference spec definitions with runtime findings to identify endpoints that accept external URLs and use static API key headers without input validation or allowlist controls.

SSRF severity often depends on what the API key can access. In Chi, binding to localhost may be restricted, but cloud metadata endpoints or internal service meshes may expose secrets, tokens, or configuration. middleBrick’s checks include Data Exposure and Input Validation to surface these risks and provide remediation guidance that focuses on URL allowlists, host resolution controls, and avoiding automatic propagation of API keys to user-influenced destinations.

Remediation focuses on preventing user-controlled input from influencing request targets and ensuring API keys are not attached to untrusted outbound calls. In Chi, you should validate and restrict allowed hosts before making outbound requests and avoid propagating API keys automatically.

Use a strict allowlist of hostnames or IPs and reject requests that target internal or sensitive addresses. Do not rely on port-based filtering alone, as attackers can bypass using URL-encoded formats or mixed-case hosts.

package main

import (
    "errors"
    "net"
    "net/http"
    "net/url"
    "os"
    "strings"
)

var allowedHosts = map[string]bool{
    "api.example.com": true,
    "data.example.com": true,
}

func isAllowedHost(rawURL string) error {
    parsed, err := url.Parse(rawURL)
    if err != nil {
        return errors.New("invalid url")
    }
    host := parsed.Hostname()
    if !allowedHosts[host] {
        return errors.New("host not allowed")
    }
    // optionally resolve and verify not pointing to private ranges
    ips, resolveErr := net.LookupIP(host)
    if resolveErr != nil {
        return resolveErr
    }
    for _, ip := range ips {
        if ip.To4() != nil && isPrivateIPv4(ip.String()) {
            return errors.New("host resolves to private address")
        }
    }
    return nil
}

func isPrivateIPv4(ip string) bool {
    parsed := net.ParseIP(ip)
    return parsed.To4() != nil && (parsed[0] == 10 || (parsed[0] == 172 && parsed[1] >= 16 && parsed[1] <= 31) || (parsed[0] == 192 && parsed[1] == 168))
}

func main() {
    http.HandleFunc("/forward", func(w http.ResponseWriter, r *http.Request) {
        target := r.URL.Query().Get("url")
        if err := isAllowedHost(target); err != nil {
            http.Error(w, err.Error(), http.StatusBadRequest)
            return
        }
        // Use a backend client configured with credentials scoped to the allowed host
        apiKey := os.Getenv("API_KEY")
        req, _ := http.NewRequest(r.Method, target, r.Body)
        req.Header.Set("Authorization", "Bearer "+apiKey)
        client := &http.Client{}
        resp, _ := client.Do(req)
        defer resp.Body.Close()
        w.WriteHeader(resp.StatusCode)
    })
}

Additionally, avoid attaching API keys to requests that originate from user input. Instead, use backend credentials scoped to specific integrations or services, and rotate keys regularly. In Chi, you can centralize outbound HTTP logic to enforce these policies consistently across handlers. middleBrick’s scan results can help identify endpoints where API keys are exposed in SSRF-prone contexts, and its findings align with remediation guidance such as host allowlists and input validation tied to compliance frameworks like OWASP API Top 10 and SOC2.