Missing Tls in Echo Go with Basic Auth
Missing Tls in Echo Go with Basic Auth — how this specific combination creates or exposes the vulnerability
Using HTTP Basic Authentication in an Echo Go application without Transport Layer Security (TLS) exposes credentials in transit. Basic Auth encodes the username and password with Base64, which is trivial to decode. Without TLS, the Authorization header travels in plaintext across the network and can be intercepted by an adversary conducting passive sniffing or active man-in-the-middle (MITM) attacks.
An unauthenticated scan with middleBrick will flag this as a finding under Data Exposure and Encryption checks. middleBrick tests the unauthenticated attack surface and, when TLS is absent, reports that credentials are transmitted without confidentiality. This combination also intersects with Authentication and Unsafe Consumption checks, because weak transport security undermines the protection of the authentication mechanism itself.
Consider an Echo Go handler that reads the Authorization header and performs a simple comparison:
package main
import (
"net/http"
"strings"
"github.com/labstack/echo/v4"
)
func main() {
e := echo.New()
e.GET("/admin", func(c echo.Context) error {
auth := c.Request().Header.Get("Authorization")
if auth == "Basic dXNlcjpwYXNz" { // user:pass in Base64
return c.String(http.StatusOK, "OK")
}
return echo.ErrUnauthorized
})
e.Start(":8080")
}
In this example, the credentials are compared against a hard‑coded Base64 string. If an attacker intercepts the request on a network without TLS, they can extract the Authorization header, decode the Base64 payload, and obtain the plaintext credentials. middleBrick’s detection of missing TLS highlights this exposure and emphasizes that authentication mechanisms must operate over encrypted channels.
When TLS is missing, other risks amplify. An attacker could modify the response (e.g., inject malicious JavaScript if the handler serves HTML) or redirect the client to a malicious endpoint, leveraging the lack of integrity protection. middleBrick’s SSRF and Property Authorization checks may further surface downstream effects when endpoints are called without encryption. Remediation requires enabling TLS so that all authentication exchanges are protected by encryption and integrity guarantees.
Basic Auth-Specific Remediation in Echo Go — concrete code fixes
To remediate the missing TLS risk while using Basic Auth in Echo Go, enforce HTTPS by configuring TLS on the Echo instance and avoiding any fallback to HTTP. Below is a secure example that loads TLS certificates and starts the server with encryption enabled.
package main
import (
"net/http"
"strings"
"github.com/labstack/echo/v4"
)
func main() {
e := echo.New()
e.GET("/admin", func(c echo.Context) error {
auth := c.Request().Header.Get("Authorization")
const expected = "Basic dXNlcjpwYXNz" // user:pass Base64
if auth != expected {
return echo.ErrUnauthorized
}
return c.String(http.StatusOK, "OK")
})
// Enforce TLS: provide cert and key file paths
// Do NOT start e.Start(":8080") without TLS in production
err := e.StartTLS(":8443", "cert.pem", "key.pem")
if err != nil && err != http.ErrServerClosed {
panic(err)
}
}
In this corrected implementation, the server only listens on TLS-enabled HTTPS. The handler still inspects the Authorization header, but credentials are now protected in transit. middleBrick’s Encryption and Data Exposure checks will validate that TLS is active and that no cleartext HTTP endpoints expose authentication logic.
Additional hardening steps include:
- Use HTTP strict transport security (HSTS) headers to prevent downgrade attacks.
- Avoid logging Authorization headers to prevent accidental credential leakage in logs.
- Prefer more secure authentication mechanisms, such as token-based approaches with short lifetimes, but if Basic Auth is required, ensure it is only used over TLS.
middleBrick’s GitHub Action can be configured to fail builds if a scan detects missing TLS on endpoints using authentication, helping to prevent regressions. The CLI can be run locally with middlebrick scan https://your-api.example.com to verify that TLS is enforced before deployment.
Related CWEs: encryption
| CWE ID | Name | Severity |
|---|---|---|
| CWE-319 | Cleartext Transmission of Sensitive Information | HIGH |
| CWE-295 | Improper Certificate Validation | HIGH |
| CWE-326 | Inadequate Encryption Strength | HIGH |
| CWE-327 | Use of a Broken or Risky Cryptographic Algorithm | HIGH |
| CWE-328 | Use of Weak Hash | HIGH |
| CWE-330 | Use of Insufficiently Random Values | HIGH |
| CWE-338 | Use of Cryptographically Weak PRNG | MEDIUM |
| CWE-693 | Protection Mechanism Failure | MEDIUM |
| CWE-757 | Selection of Less-Secure Algorithm During Negotiation | HIGH |
| CWE-261 | Weak Encoding for Password | HIGH |