Api Key Exposure in Gin with Oauth2

When an API built with the Gin framework uses OAuth 2.0, developers sometimes conflate access tokens with API keys or inadvertently expose keys through token handling, creating an Api Key Exposure finding. OAuth 2.0 is an authorization framework that issues bearer tokens; it does not inherently manage long-lived API keys. A typical misconfiguration occurs when a Gin service accepts both an OAuth 2.0 bearer token and a static API key (for example, via an X-API-Key header) and routes or proxies requests to downstream services. If the upstream service expects an API key and the Gin layer embeds a hardcoded key or logs it, the key can be leaked through logs, error messages, or inadvertently returned to clients.

Another common pattern is using OAuth 2.0 to authorize user access while a separate service-to-service credential (API key) is required to call another API. If the Gin code stores that service key in environment variables but also echoes configuration into logs or debug endpoints, an attacker who can read logs or error responses may obtain the key. Additionally, if introspection or token validation endpoints are misconfigured to return sensitive headers or if middleware passes the Authorization header directly to downstream APIs without stripping it, an OAuth 2.0 access token intended for the Gin service might be forwarded as an API key to another service, causing confusion and exposure.

During a black-box scan, middleBrick tests the unauthenticated attack surface of a Gin endpoint configured with OAuth 2.0. It checks whether API keys are returned in responses, appear in documentation or OpenAPI specs, or are derivable from error payloads. The scan also examines whether the Authorization header is handled correctly, whether tokens are leaked in logs via verbose error pages, and whether introspection responses expose credentials. These checks help identify whether the combination of Gin and OAuth 2.0 leads to inadvertent key disclosure through misrouted headers, verbose logging, or overly broad scopes that grant access to configuration endpoints.

To remediate Api Key Exposure when using OAuth 2.0 in Gin, ensure tokens are treated as opaque credentials for authorization only and that no static API keys are echoed or logged. Use middleware to validate tokens and strip or transform headers before forwarding requests to downstream services. Below are concrete, working examples for Gin that demonstrate secure handling.

Example 1: Validate OAuth 2.0 Bearer Token and Remove Sensitive Headers

This middleware validates the presence of a bearer token and ensures no Authorization or API key header is forwarded to downstream services.

package main

import (
	"net/http"
	"strings"

	"github.com/gin-gonic/gin"
)

func oauth2Middleware() gin.HandlerFunc {
	return func(c *gin.Context) {
		auth := c.GetHeader("Authorization")
		if auth == "" || !strings.HasPrefix(auth, "Bearer ") {
			c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "missing or invalid bearer token"})
			return
		}
		// Optionally validate the token via introspection or JWKS here
		// For example: validateToken(auth[7:])

		// Ensure no API key is forwarded downstream
		c.Request.Header.Del("X-API-Key")
		// Strip the Authorization header if the downstream service does not need it
		// c.Request.Header.Del("Authorization")

		c.Next()
	}
}

func main() {
	r := gin.Default()
	r.Use(oauth2Middleware())

	r.GET("/resource", func(c *gin.Context) {
		c.JSON(http.StatusOK, gin.H{"message": "access granted"})
	})

	// DO NOT log headers that may contain keys or tokens
	// r.Use(gin.LoggerWithConfig(gin.LoggerConfig{
	//   SkipPaths: []string{"/health"},
	// }))

	_ = r.Run() // listening on 0.0.0.0:8080 by default
}

Example 2: Secure Service-to-Service Call with Static Key from Environment

This example retrieves a service API key from environment variables at startup and uses it securely without logging or exposing it.

package main

import (
	"os"
	"net/http"

	"github.com/gin-gonic/gin"
	"golang.org/x/oauth2"
)

var serviceKey string

func init() {
	serviceKey = os.Getenv("SERVICE_API_KEY")
	if serviceKey == "" {
		// Handle missing key at startup; do not proceed without it.
		panic("SERVICE_API_KEY environment variable is required")
	}
}

func callDownstream(ctx *gin.Context) {
	client := oauth2.NewClient(ctx.Request.Context(), oauth2.StaticTokenSource(
		&oauth2.Token{AccessToken: "unused-for-downstream"},
	))
	req, _ := http.NewRequest("GET", "https://downstream.example.com/data", nil)
	req.Header.Set("X-API-Key", serviceKey)
	req.Header.Set("User-Agent", "middleBrick-integration/1.0")

	resp, err := client.Do(req)
	if err != nil || resp.StatusCode != http.StatusOK {
		ctx.JSON(http.StatusBadGateway, gin.H{"error": "downstream error"})
		return
	}
	defer resp.Body.Close()
	// Process response without exposing serviceKey
	ctx.JSON(http.StatusOK, gin.H{"status": "ok"})
}

func main() {
	r := gin.Default()
	r.GET("/proxy", callDownstream)
	_ = r.Run()
}

OpenAPI/Swagger Alignment

Ensure your OpenAPI spec does not include examples or parameters that reveal API keys. Use securitySchemes for OAuth 2.0 and mark sensitive headers as x-sensitive: true. middleBrick’s OpenAPI/Swagger analysis resolves $ref definitions and cross-references runtime findings to detect mismatches that could lead to exposure.