Missing Tls in Chi with Basic Auth

Transport Layer Security (TLS) ensures confidentiality and integrity in transit. When a Chi-based API does not enforce TLS while using HTTP Basic Authentication, credentials are transmitted as base64-encoded plaintext with every request. base64 is not encryption; it is easily reversible. Without TLS, any observer on the network path can intercept and decode the Authorization header, recovering the username and password directly.

Chi is a lightweight router for HTTP that does not mandate TLS. If you configure routes and handlers but do not terminate TLS at a reverse proxy or within your server setup, requests reach your Chi application over cleartext HTTP. Basic Auth credentials remain in the URI or headers, making them trivially visible to anyone who can observe packets (for example, on shared WiFi, via ISP inspection, or in a compromised network).

This combination also interacts poorly with other security checks that middleBrick performs. For example, unauthenticated scanning may detect the absence of TLS and flag insecure transmission of credentials. If Basic Auth is used without TLS, middleBrick’s Authentication and Data Exposure checks will surface the risk as a high-severity finding, noting that credentials are sent in recoverable form. Attack patterns such as credential sniffing and session hijacking map directly onto this weakness, aligning with OWASP API Top 10 items related to broken authentication and data exposure.

In practice, this means an API that appears to use authentication is actually exposing secrets in the clear. middleBrick’s scans can identify Missing TLS by checking whether endpoints are served over HTTPS and whether Strict-Transport-Security headers are present. When combined with Basic Auth, Missing TLS becomes a critical exposure because the authentication mechanism itself is undermined by transmitting secrets without protection.

To remediate Missing TLS with Basic Auth in Chi, you should either enforce HTTPS at the edge or avoid Basic Auth over non-encrypted channels entirely. The safest approach is to terminate TLS at a reverse proxy or load balancer and ensure all traffic to your Chi application is over HTTPS. If you must handle TLS within the application, use a proper TLS server configuration.

Below are concrete Chi examples that show an unsafe setup and a corrected, HTTPS-enabled setup. These examples use the http and https modules from std/http, and assume you have valid certificate files for production use.

Unsafe Chi server with Basic Auth over HTTP

import chi
import http.httpclient
import base64

let router = newRoutable()

router.get("/secure"):
  let authHeader = request.headers.get("Authorization")
  if authHeader != none and authHeader.startsWith("Basic "):
    let token = authHeader.get[7..^1] # strip "Basic "
    let decoded = base64.decode(token)
    # naive check: compare against a static value — not recommended in production
    if decoded == "admin:secret":
      return {"status": "ok"}
  response.status = 401
  response.headers["WWW-Authenticate"] = "Basic realm=\"api\""
  return {"error": "unauthorized"}

# WARNING: this serves HTTP, not HTTPS
http.listen(8080, router)

This example illustrates the vulnerability: credentials are checked but sent and received over cleartext HTTP. An interceptor can read the Authorization header before the application logic runs.

Corrected Chi server with HTTPS and Basic Auth

import chi
import http.httpclient
import base64
import os

let router = newRoutable()

router.get("/secure"):
  let authHeader = request.headers.get("Authorization")
  if authHeader != none and authHeader.startsWith("Basic "):
    let token = authHeader.get[7..^1]
    let decoded = base64.decode(token)
    # validate credentials securely — use constant-time comparison and a store
    if decoded == "admin:secret":
      return {"status": "ok"}
  response.status = 401
  response.headers["WWW-Authenticate"] = "Basic realm=\"api\""
  return {"error": "unauthorized"}

# Serve over HTTPS with certificate and key paths
let cert = "path/to/fullchain.pem"
let key = "path/to/privkey.pem"
https.listen(8443, router, cert, key)

In the corrected example, the server listens on HTTPS, ensuring that all traffic including Basic Auth headers is encrypted in transit. You should use strong credential storage (not hardcoded strings) and prefer token-based or session-based authentication where feasible. middleBrick’s Authentication checks will validate the presence of TLS and flag endpoints served over HTTP when authentication mechanisms like Basic Auth are in use.

Additionally, you can integrate the middleBrick CLI to scan your Chi endpoints from the terminal: middlebrick scan https://your-api.example.com. The CLI outputs JSON or text findings, including Authentication and Data Exposure results, so you can verify that TLS is enforced and Basic Auth credentials are not transmitted in cleartext. For automated pipeline controls, the GitHub Action can fail builds if the score drops below your chosen threshold, and the MCP Server lets you scan APIs directly from your IDE while developing Chi handlers.