Api Key Exposure in Echo Go with Oauth2

When an Echo Go service exposes an API key while also using OAuth 2.0 flows, the combination can inadvertently disclose secrets through misconfigured handlers, logs, or error responses. API keys are often stored as bearer credentials or injected into request headers by the application, while OAuth 2.0 introduces access tokens issued by an authorization server. If the Echo Go handler merges or logs both credential types without care, an attacker who triggers an error or intercepts a response may see the API key in plaintext or recover it from logs.

For example, consider an Echo Go route that calls a downstream service using an API key while also validating an incoming OAuth 2.0 access token. If the developer accidentally includes the API key in URLs, query parameters, or response bodies during error handling, the key becomes exposed. OAuth 2.0 error responses (e.g., invalid_token) might be verbose and inadvertently include environment variables or headers containing the API key, especially when debugging middleware is active. This violates the principle of least privilege and separation of concerns, because OAuth 2.0 access tokens are meant to represent delegated access, while API keys often serve as long-lived service credentials.

Echo Go applications that use the standard net/http pattern with middleware may log each request’s headers for debugging. If the API key is stored in an environment variable and attached to outgoing requests as a header, and the incoming OAuth 2.0 request also carries sensitive headers, a single log line can expose both. Attackers can exploit misconfigured CORS or redirect endpoints to trick clients into making authenticated calls that reveal error messages containing the API key. Additionally, if introspection endpoints or token revocation logic echo back provided identifiers without sanitization, the API key may be reflected in JSON responses, making it accessible to unauthorized parties.

Common root causes include:

• Concatenating API keys with OAuth 2.0 parameters in query strings.
• Returning detailed errors that include the Authorization header values.
• Using the same context or request-scoped values for both token types without isolation.

These patterns can be identified by a scanner that performs OAuth 2.0-specific probing and output scanning, such as active prompt injection tests and checks for PII or secrets in responses. In this scenario, the scanner would flag the presence of an API key in error outputs or logs and highlight the unsafe handling of OAuth 2.0 tokens alongside long-lived credentials.

Remediation focuses on isolating OAuth 2.0 tokens from API keys, avoiding leakage in logs and responses, and following secure coding practices in Echo Go.

1. Keep API keys out of responses and logs. Ensure that middleware does not log full headers, and scrub sensitive keys before writing to any output. Use structured logging with field-level redaction for Authorization headers.

2. Separate the handling of OAuth 2.0 tokens and API keys. Use distinct contexts or variables so that an OAuth 2.0 access token is never concatenated with an API key in URLs or query parameters.

3. Validate and sanitize all incoming OAuth 2.0 error responses to avoid reflecting sensitive values. Use standard, minimal error structures that do not include headers or internal identifiers.

Below are concrete, secure code examples for Echo Go that demonstrate these principles.

package main

import (
	"context"
	"log/slog"
	"net/http"
	"os"

	"github.com/labstack/echo/v4"
	"golang.org/x/oauth2"
)

// Secure handler: uses OAuth2 token for authorization, API key kept server-side.
func proxyHandler(c echo.Context) error {
	// OAuth2 token from incoming request (e.g., Bearer token)
	token := c.Request().Header.Get("Authorization")
	if token == "" {
		return echo.NewHTTPError(http.StatusUnauthorized, "missing authorization token")
	}

	// Validate token via OAuth2 introspection (example using oauth2.Config)
	// In production, call the provider’s introspection endpoint securely.
	src := oauth2.StaticTokenSource(&oauth2.Token{AccessToken: token})
	ctx := oauth2.NewClient(c.Request().Context(), src)

	// API key is read from environment and used only server-side, never exposed to client.
	apiKey := os.Getenv("UPSTREAM_API_KEY")
	if apiKey == "" {
		return echo.NewHTTPError(http.StatusInternalServerError, "server configuration error")
	}

	// Create a new request to the downstream service.
	req, err := http.NewRequest(http.MethodGet, "https://api.example.com/data", nil)
	if err != nil {
		return echo.NewHTTPError(http.StatusInternalServerError, "failed to create request")
	}

	// Set OAuth2 token for upstream if required; do NOT append API key to URL.
	req.Header.Set("Authorization", "Bearer "+token)
	// Attach API key as a custom header only when necessary and avoid logging it.
	req.Header.Set("X-Upstream-Key", apiKey)

	// Perform the request with the OAuth2 client (ctx carries the token).
	resp, err := http.DefaultClient.Do(req.WithContext(ctx))
	if err != nil {
		// Return generic error without exposing headers or keys.
		slog.Error("proxy request failed", "error", err.Error())
		return echo.NewHTTPError(http.StatusBadGateway, "unable to fetch data")
	}
	defer resp.Body.Close()

	// Stream response back without exposing sensitive headers.
	c.Response().WriteHeader(resp.StatusCode)
	_, _ = c.Response().Write([]byte("proxied data")) // simplified; use io.Copy in production.
	return nil
}

func main() {
	e := echo.New()

	// Use middleware that scrubs sensitive headers from logs.
	e.Use(func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c echo.Context) error {
			// Example: remove Authorization from logs (implementation depends on logger).
			req := c.Request()
			if req.Header.Get("Authorization") != "" {
				// Ensure logs do not capture the full header value.
				slog.Info("request received", "path", req.URL.Path)
			} else {
				slog.Info("request received", "path", req.URL.Path)
			}
			return next(c)
		}
	})

	e.GET("/proxy", proxyHandler)
	e.Logger.Fatal(e.Start(":8080"))
}

Key points in the example:

• The API key is read from the server environment and attached as a custom header only when required, never sent to the client or logged.
• OAuth 2.0 access tokens are passed as Bearer tokens in the Authorization header, keeping token handling separate from API key usage.
• Error messages are generic and do not reflect Authorization header values or internal configuration.
• Middleware can be used to scrub sensitive headers from logs, reducing the risk of accidental exposure.

For production, also enforce HTTPS, use short-lived OAuth 2.0 tokens, and rotate API keys regularly. A scanner with OAuth 2.0 active probing can validate that tokens are not reflected improperly and that API keys remain hidden from the client and logs.