Missing Tls in Echo Go with Bearer Tokens

When an Echo Go service uses Bearer Tokens over unencrypted HTTP, tokens are exposed in transit, enabling interception and replay. Transport Layer Security (TLS) protects confidentiality and integrity; without it, credentials travel as plaintext regardless of how the token is formatted in the Authorization header.

In an unauthenticated scan, middleBrick checks whether API endpoints are served over HTTPS and whether sensitive inputs like tokens are transmitted in clear text. A missing TLS configuration is flagged as a high-severity data exposure risk because any network observer on the path can capture the token. This becomes critical in shared or untrusted networks where passive sniffing is trivial.

The combination is especially risky because Bearer Tokens are often long-lived compared to session cookies, and they are typically sent with every request. If an API endpoint lacks TLS, an attacker who observes a single token can reuse it until expiration or revocation. Even if the token is rotated, the absence of encryption means rotation events can also be observed. MiddleBrick’s checks include Data Exposure and Encryption, and when TLS is absent, the scan will highlight the lack of transport protection alongside the presence of token-based authentication as compounding factors.

SSRF and Inventory Management checks may also surface related issues: for example, an internal redirect or service discovery call that inadvertently leaks the token to an unencrypted endpoint. Because middleBrick tests the unauthenticated attack surface, it can detect endpoints that require a token in the header yet fail to enforce transport-level confidentiality, aligning findings with OWASP API Top 10:2023 —2: Broken Object Level Authorization and A02:2023 — Cryptographic Failures.

Remediation requires enforcing HTTPS on the server and ensuring the client sends tokens only over encrypted channels. Below are concrete, working examples for an Echo Go service with Bearer Token validation.

Enforce TLS on the server

Configure Echo to serve only over HTTPS with a valid certificate. Self-signed certs are acceptable for testing but should be replaced with certificates from a trusted CA in production.

// server.go
package main

import (
    "log"
    "net/http"

    "github.com/labstack/echo/v4"
    "github.com/labstack/echo/v4/middleware"
)

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

    // Enforce TLS and secure headers
    e.Use(middleware.SecureWithConfig(middleware.SecureConfig{
        SSLRedirect: true,
        SSLHost:     "api.example.com",
    }))

    e.GET('/protected', func(c echo.Context) error {
        token := c.Request().Header.Get("Authorization")
        if !isValidBearerToken(token) {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid or missing token")
        }
        return c.String(http.StatusOK, "access granted")
    })

    // Use TLS configuration with certificates
    if err := e.StartTLS(":443", "cert.pem", "key.pem"); err != nil {
        log.Fatalf("failed to start TLS server: %v", err)
    }
}

func isValidBearerToken(token string) bool {
    // Implement proper validation, e.g., check against a store or validate JWT
    return len(token) > 0 && len(token) < 1024
}

Client-side: send tokens only over HTTPS

Clients must construct requests with https:// and include the Bearer Token in the Authorization header. Never send tokens over HTTP or embed them in URLs or query parameters.

// client.go
package main

import (
    "fmt"
    "net/http"
)

func main() {
    token := "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" // example token
    req, err := http.NewRequest("GET", "https://api.example.com/protected", nil)
    if err != nil {
        panic(err)
    }
    req.Header.Set("Authorization", "Bearer "+token)

    client := &http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    fmt.Println("Response status:", resp.StatusCode)
}

Additional server hardening

Use secure cookies if storing tokens server-side, set short timeouts, and validate token format strictly. middleBrick’s Property Authorization and Input Validation checks can help verify that token handling logic does not introduce parsing ambiguities or injection paths.