Ssrf in Echo Go with Bearer Tokens

Server-Side Request Forgery (SSRF) in the Echo Go framework becomes more nuanced when APIs rely on Bearer Tokens for outbound authorization. In this setup, an attacker can coerce the server into making requests to internal or unexpected endpoints while those requests carry a trusted Bearer Token. The token may be intended only for calls originating from trusted services, but when an attacker can influence the target URL, the server acts as a proxy that forwards the token to arbitrary destinations.

Consider an internal service that accepts a URL and an optional Authorization header to call another API. If the endpoint does not validate or restrict the target host and blindly forwards a request with a Bearer Token extracted from an incoming Authorization header, an SSRF vector is created. The token’s scope, which should be limited to specific services, is inadvertently extended to internal metadata services, cloud instance metadata endpoints, or on-prem resources behind firewalls. In Echo Go, this often happens when developers use a client with a per-request config that copies headers without strict allowlisting of hosts.

For example, an attacker might supply a URL pointing to http://169.254.169.254/latest/meta-data/iam/security-credentials/ on an EC2 instance. If the server uses a shared HTTP client and includes the original Bearer Token in the forwarded request, the metadata response may be returned to the attacker, exposing credentials or instance roles. The vulnerability is not about how Echo Go handles tokens internally; it’s about how the application uses the framework to build outbound requests while propagating or reusing authentication material without proper validation.

An SSRF chain involving Bearer Tokens can also lead to token exfiltration when combined with other weaknesses such as Server-Side Template Injection or insecure deserialization. Because the token is included in outbound requests, an attacker can use SSRF to route traffic to an attacker-controlled server that logs the Authorization header. This turns a seemingly harmless URL fetch into a credential harvesting path. The risk is compounded when the token has broader permissions than necessary, such as write access to storage or ability to invoke other internal APIs.

MiddleBrick identifies this pattern during scans by cross-referencing OpenAPI specifications with runtime behavior. If an endpoint accepts a URL input and uses bearer-based authorization in outbound calls without host restrictions, the scan highlights the exposure. The scanner does not modify tokens or alter runtime behavior; it surfaces the pathway where a token can be leaked or abused through SSRF, providing remediation steps to constrain destinations and validate outbound targets.

Remediation focuses on preventing the server from blindly forwarding requests to arbitrary hosts and ensuring Bearer Tokens are not unintentionally propagated. The safest approach is to avoid copying the incoming Authorization header to outbound requests unless absolutely necessary. Instead, use a dedicated service token with a narrowly scoped role that is configured via environment variables, not derived from user input.

Example of a vulnerable pattern in Echo Go where an incoming Authorization header is forwarded:

c := e.Get("").(*echo.Context)
req, _ := http.NewRequest(echo.GET, targetURL, nil)
if auth := c.Request().Header.Get("Authorization"); auth != "" {
    req.Header.Set("Authorization", auth)
}
resp, err := http.DefaultClient.Do(req)

This pattern copies the client’s Bearer Token to any target URL, enabling SSRF-based token leakage.

Secure alternative using a fixed service token and strict host validation:

allowedHosts := map[string]bool{
    "api.svc.example.com": true,
    "internal.service.local": true,
}

func isHostAllowed(urlStr string) bool {
    u, err := url.Parse(urlStr)
    if err != nil {
        return false
    }
    return allowedHosts[u.Host]
}

func makeServiceCall(targetURL string, serviceToken string) (*http.Response, error) {
    if !isHostAllowed(targetURL) {
        return nil, errors.New("target not allowed")
    }
    req, err := http.NewRequest(http.MethodGet, targetURL, nil)
    if err != nil {
        return nil, err
    }
    req.Header.Set("Authorization", "Bearer "+serviceToken)
    client := &http.Client{}
    return client.Do(req)
}

In this approach, the incoming request’s Authorization header is never reused. A service-specific token is used instead, and the target host is validated against an allowlist. This prevents SSRF from being used to reach internal endpoints or cloud metadata services while ensuring that outbound calls are authenticated with a token scoped only to intended destinations.

When using the CLI (middlebrick scan <url>), the GitHub Action for CI/CD, or the MCP Server in your AI coding assistant, you can validate that your API endpoints follow these patterns. MiddleBrick detects configurations where tokens are propagated to untrusted hosts and maps findings to frameworks such as OWASP API Top 10 and PCI-DSS, so teams can prioritize fixes without relying on guesswork.