Api Key Exposure in Echo Go with Jwt Tokens

When an Echo Go service uses JWT tokens for authorization but also exposes API keys through insecure handling, the combined pattern increases the likelihood of sensitive material leakage. In this scenario, JWT tokens often carry identity and scope claims, while API keys act as a second factor or service-to-service credential. If either token or key is mishandled—such as being logged, echoed in error messages, or returned in HTTP responses—an attacker can harvest both the JWT and the key from the same endpoint.

Echo Go applications that embed API keys inside JWT claims, headers, or query parameters without proper redaction risk exposing secrets in logs, traces, or browser history. For example, middleware that logs the full Authorization header might inadvertently record both the Bearer JWT and an additional x-api-key header. Because JWT tokens are often long-lived compared to session cookies, a leaked token paired with a leaked API key can allow extended access to backend services, configuration stores, or message queues.

Another common pattern is the use of JWTs to authorize requests that themselves call downstream APIs protected by API keys. If the Echo Go service constructs those downstream calls by concatenating static keys with dynamic JWT-derived parameters, and does not sanitize inputs, an SSRF or injection vector may expose the key through error replies or verbose responses. The interplay between JWT-based identity and key-based service credentials means that weaknesses in token validation or key storage can amplify the blast radius of a single misconfiguration.

Real-world findings from scans of Echo Go endpoints have shown JWT tokens in URL paths and API keys in response bodies, both of which are categorized as Data Exposure. When combined, these findings map to OWASP API Top 10:2023 A05 (Security Misconfiguration) and A07 (Identification and Authentication Failures), and can align with compliance frameworks such as PCI-DSS and SOC2 controls around secret management. The risk is especially acute when tokens contain excessive agency patterns, such as custom claims that imply broader privileges than intended.

middleBrick detects these conditions by analyzing OpenAPI specifications and runtime responses for signs of key and token leakage, flagging items like keys in error messages, tokens in logs, and unauthenticated endpoints that should be protected. The scanner does not fix the configuration, but provides prioritized findings with remediation guidance to help developers redesign how JWT tokens and API keys coexist safely.

Remediation focuses on preventing JWT and API key material from appearing in logs, error responses, or browser-side storage, and on enforcing strict validation and least privilege. Below are concrete, idiomatic Go code examples using the standard net/http package and a common JWT library approach.

First, ensure JWT tokens are validated securely and never reflected in responses. Do not return the raw token in JSON payloads. Instead, verify the token and use its claims to enforce authorization, keeping the token opaque to the client as much as possible.

package main

import (
	"context"
	"fmt"
	"net/http"
	"strings"

	"github.com/golang-jwt/jwt/v5"
)

var jwtKey = []byte("your-secret-key")

type Claims struct {
	Scope string `json:"scope"`
	jwt.RegisteredClaims
}

func authMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		authHeader := r.Header.Get("Authorization")
		if authHeader == "" {
			http.Error(w, `{"error": "authorization header required"}`, http.StatusUnauthorized)
			return
		}
		bearerToken := strings.TrimPrefix(authHeader, "Bearer ")
		token, err := jwt.ParseWithClaims(bearerToken, &Claims{}, func(token *jwt.Token) (interface{}, error) {
			return jwtKey, nil
		})
		if err != nil || !token.Valid {
			http.Error(w, `{"error": "invalid token"}`, http.StatusUnauthorized)
			return
		}
		claims, ok := token.Claims.(*Claims)
		if !ok {
			http.Error(w, `{"error": "invalid claims"}`, http.StatusUnauthorized)
			return
		}
		ctx := context.WithValue(r.Context(), "scope", claims.Scope)
		next.ServeHTTP(w, r.WithContext(ctx))
	})
}

func handler(w http.ResponseWriter, r *http.Request) {
	// Use claims from context; do not echo the JWT back to the client
	scope := r.Context().Value("scope").(string)
	fmt.Fprintf(w, `{"scope": "%s"}`, scope)
}

func main() {
	mux := http.NewServeMux()
	mux.Handle("/api/data", authMiddleware(http.HandlerFunc(handler)))
	http.ListenAndServe(":8080", mux)
}

Second, avoid logging or concatenating the JWT with API keys. If you must pass an API key to a downstream service, store it securely outside of the request context and ensure it is never written to logs or error responses. Use structured logging that redacts sensitive fields.

package main

import (
	"log"
	"net/http"
	"os"n"
)

func proxyHandler(w http.ResponseWriter, r *http.Request) {
	apiKey := os.Getenv("DOWNSTREAM_API_KEY")
	if apiKey == "" {
		http.Error(w, `{"error": "service unavailable"}`, http.StatusServiceUnavailable)
		return
	}
	// Do NOT log apiKey or include it in any response
	req, _ := http.NewRequest(r.Method, "https://downstream.example.com/resource", r.Body)
	req.Header.Set("Authorization", "Bearer "apiKey)
	// Perform the request and forward the response without exposing secrets
	// ...
}

Third, apply principle of least privilege to JWT claims and API key scopes. Ensure tokens do not carry overly broad permissions and keys are scoped to the minimum required operations. Rotate keys regularly and use short-lived JWTs where feasible. middleBrick can validate these controls by scanning your OpenAPI spec for overly permissive security schemes and reporting findings that indicate missing or weak token validation.