Information Disclosure in Echo Go with Bearer Tokens

Information disclosure in Echo Go applications that use Bearer tokens typically occurs when token handling, logging, and HTTP routing intersect in ways that expose sensitive credentials or data to unauthorized parties. When an Echo Go service accepts Bearer tokens in HTTP headers and does not carefully control what is logged or how requests are processed, the token can appear in access logs, error traces, or debug output, leading to unintended exposure.

For example, if middleware logs the full request headers without redacting the Authorization header, a Bearer token such as Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 can be written to logs that may be accessible to less-privileged users or external log aggregation systems. This represents a classic information disclosure vector because the token grants privileged access to downstream services. In an API security scan, findings related to data exposure often highlight such logging misconfigurations, especially when combined with missing input validation that allows attackers to inject crafted headers that are then reflected in responses or logs.

Echo Go applications that expose unauthenticated endpoints while accepting Bearer tokens for other routes can also leak information through inconsistent error handling. An endpoint that returns verbose errors when a malformed or missing Bearer token is provided may disclose stack traces or internal paths, inadvertently revealing implementation details. Cross-referencing runtime behavior with an OpenAPI specification helps identify mismatches between documented authentication requirements and actual behavior. Without proper safeguards, attackers can probe these discrepancies to map exposed endpoints and token handling quirks.

The combination of weak logging practices, insufficient input validation, and overly verbose error responses creates a scenario where Bearer tokens and associated session information can be harvested through low-effort reconnaissance. This aligns with common findings in OWASP API Top 10 categories such as Broken Object Level Authorization (BOLA) and Sensitive Data Exposure, where tokens and data are exposed due to missing controls. Regular scans with tools that test unauthenticated attack surfaces can surface these issues by analyzing how the service responds to malformed or missing tokens and whether sensitive data appears in outputs or logs.

To reduce risk, developers should ensure that Authorization headers are stripped or redacted before logging, implement strict input validation on header values, and standardize error responses to avoid revealing internal paths or token formats. Continuous monitoring and scanning, such as that provided by the middleBrick Pro plan with its continuous monitoring and GitHub Action integration, helps catch regressions before they reach production by failing builds when security scores drop below a defined threshold.

Remediation focuses on preventing Bearer tokens from leaking through logs, error messages, or inconsistent handling. Below are concrete Go code examples using the github.com/labstack/echo/v4 framework that demonstrate secure practices.

1. Redacting Authorization headers in middleware

Create middleware that removes or masks the Authorization header before logging requests. This prevents tokens from appearing in access logs.

import (
    "github.com/labstack/echo/v4"
    "net/http"
)

func RedactAuthMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        // Redact Authorization header from logs
        if auth := c.Request().Header.Get("Authorization"); auth != "" {
            // Replace with a placeholder in the cloned request for logging
            redactedReq := c.Request().Clone(c.Request().Context())
            redactedReq.Header.Set("Authorization", "Bearer [REDACTED]")
            // Use redactedReq for any logging as needed
            _ = redactedReq
        }
        return next(c)
    }
}

func protectedHandler(c echo.Context) error {
    token := c.Request().Header.Get("Authorization")
    if token == "" {
        return c.JSON(http.StatusUnauthorized, map[string]string{"error": "missing bearer token"})
    }
    // Validate token and proceed
    return c.JSON(http.StatusOK, map[string]string{"status": "ok"})
}

2. Validating Bearer token format and presence

Ensure tokens follow expected formats and are not empty or malformed before processing. This reduces information leakage through errors.

func ValidateBearer(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        authHeader := c.Request().Header.Get("Authorization")
        if authHeader == "" {
            // Generic error to avoid revealing token requirements
            return c.JSON(http.StatusUnauthorized, map[string]string{"error": "unauthorized"})
        }
        // Expecting "Bearer "
        const bearerPrefix = "Bearer "
        if len(authHeader) < len(bearerPrefix) || authHeader[:len(bearerPrefix)] != bearerPrefix {
            return c.JSON(http.StatusBadRequest, map[string]string{"error": "bad request"})
        }
        token := authHeader[len(bearerPrefix):]
        if len(token) == 0 {
            return c.JSON(http.StatusBadRequest, map[string]string{"error": "bad request"})
        }
        // Store token securely for downstream use
        c.Set("token", token)
        return next(c)
    }
}

3. Standardizing error responses to avoid verbose leaks

Use consistent error formats that do not expose stack traces or internal paths, especially when Bearer token validation fails.

func ErrorHandler(err error, c echo.Context) {
    code := http.StatusInternalServerError
    if echoHTTPError, ok := err.(*echo.HTTPError); ok {
        code = echoHTTPError.Code
    }
    // Do not include detailed error messages or paths in production
    c.JSON(code, map[string]string{"error": "request failed"})
}

func main() {
    e := echo.New()
    e.Use(middleware.RequestLoggerWithConfig(middleware.RequestLoggerConfig{
        LogFunc: func(c echo.Context, s string) error {
            // Custom logger that redacts Authorization
            return nil
        },
    }))
    e.Use(RedactAuthMiddleware)
    e.Use(ValidateBearer)
    e.HTTPErrorHandler = ErrorHandler
    e.GET("/secure", func(c echo.Context) error {
        return c.JSON(http.StatusOK, map[string]string{"message": "secure data"})
    })
    e.Logger.Fatal(e.Start(":8080"))
}

4. Secure token handling in client and server exchanges

When tokens are issued or validated, ensure they are transmitted only over TLS and are not embedded in URLs or logs. The following pattern avoids exposing tokens in query parameters or logs.

// Example of secure token usage in a handler
func TokenIntrospect(c echo.Context) error {
    token := c.Get("token").(string)
    // Use token securely without logging it
    isValid := checkTokenValidity(token)
    return c.JSON(http.StatusOK, map[string]bool{"active": isValid})
}

func checkTokenValidity(token string) bool {
    // Perform validation against an auth provider
    return token == "expected-secure-token-value"
}