Pii Leakage in Gorilla Mux with Basic Auth
Pii Leakage in Gorilla Mux with Basic Auth — how this specific combination creates or exposes the vulnerability
Pii Leakage occurs when personally identifiable information such as email addresses, user IDs, or tokens is transmitted or stored without adequate protection. In a Gorilla Mux-based service that uses HTTP Basic Authentication, the combination of routing logic and credential handling can inadvertently expose Pii if requests are mishandled or logged.
Gorilla Mux is a powerful URL router and dispatcher for Go. When paired with Basic Auth, developers often validate credentials per request and then pass the authenticated identity (for example, a user ID or email extracted from the Basic Auth token) into downstream handlers, query parameters, or logs. If these values are included in URLs, response bodies, or logs without encryption or access controls, Pii can be exposed to unauthorized parties.
Consider a handler that decodes Basic Auth and injects the user email into a JSON response for debugging or tracing. If the response is cached, mirrored, or logged in plaintext, the Pii (email) can be read by anyone with access to logs or cache stores. Additionally, if a request with Basic Auth credentials is redirected to an insecure endpoint or proxied without stripping the Authorization header, the credentials and associated identity information may be leaked to unintended services.
Another scenario involves reflection attacks where user-controlled parameters (e.g., a user-supplied profile_id) are combined with authenticated identity. If the application uses the authenticated user’s Pii to construct error messages or audit entries without proper sanitization, an attacker who can influence the input may cause sensitive information to be returned in responses or written to logs.
middleBrick detects these patterns by analyzing the unauthenticated attack surface and cross-referencing OpenAPI specifications with runtime behavior. For example, if a spec defines an endpoint that returns user information and the runtime shows that Basic Auth is used without encryption or output filtering, middleBrick highlights the risk of Pii Leakage, maps findings to frameworks such as OWASP API Top 10 and GDPR, and provides remediation guidance.
Basic Auth-Specific Remediation in Gorilla Mux — concrete code fixes
To mitigate Pii Leakage in Gorilla Mux when using Basic Auth, ensure credentials are handled minimally, never logged or echoed, and transmitted only over TLS. Use middleware to validate and strip sensitive headers, avoid reflecting user identity in responses, and enforce strict transport security.
Below are concrete, working code examples that demonstrate secure handling of Basic Auth in Gorilla Mux routes.
package main
import (
"encoding/base64"
"fmt"
"net/http"
"strings"
"github.com/gorilla/mux"
)
// BasicAuthMiddleware validates Authorization header and extracts identity without logging it.
func BasicAuthMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
auth := r.Header.Get("Authorization")
if auth == "" {
http.Error(w, `{"error": "authorization header required`}, http.StatusUnauthorized)
return
}
const prefix = "Basic "
if !strings.HasPrefix(auth, prefix) {
http.Error(w, `{"error": "invalid authorization type`}, http.StatusUnauthorized)
return
}
payload, err := base64.StdEncoding.DecodeString(auth[len(prefix):])
if err != nil {
http.Error(w, `{"error": "invalid authorization token`}, http.StatusUnauthorized)
return
}
// Expecting "username:password"; avoid storing or echoing the full token.
kv := strings.SplitN(string(payload), ":", 2)
if len(kv) != 2 || kv[0] == "" || kv[1] == "" {
http.Error(w, `{"error": "invalid credentials format`}, http.StatusUnauthorized)
return
}
username, password := kv[0], kv[1]
// Validate credentials (replace with secure check, e.g., constant-time compare).
if !isValidUser(username, password) {
http.Error(w, `{"error": "invalid credentials`}, http.StatusUnauthorized)
return
}
// Inject minimal identity into context; do not include Pii unless strictly necessary.
ctx := context.WithValue(r.Context(), "user", username)
next.ServeHTTP(w, r.WithContext(ctx))
})
}
func isValidUser(username, password string) bool {
// Example: constant-time comparison and secure credential store lookup.
// In production, use a hashed password store and avoid plaintext handling.
return username == "alice" && password == "s3cret"
}
// Handler that avoids echoing Pii and prevents leakage via logs or responses.
func ProfileHandler(w http.ResponseWriter, r *http.Request) {
user, ok := r.Context().Value("user").(string)
if !ok {
http.Error(w, `{"error": "unauthorized`}, http.StatusUnauthorized)
return
}
// Do NOT include user-identifying details in response unless required and consented.
// If you must return user data, ensure fields are vetted for Pii and served over HTTPS.
w.Header().Set("Content-Type", "application/json")
fmt.Fprintf(w, `{"status": "ok", "user": "%s"}`, user)
}
func main() {
r := mux.NewRouter()
r.Use(BasicAuthMiddleware)
r.HandleFunc("/profile", ProfileHandler).Methods("GET")
// Enforce HTTPS in production; this example assumes TLS termination at the proxy.
http.ListenAndServeTLS(":8443", "server.crt", "server.key", r)
}
Key remediation points:
- Do not log the Authorization header or any derived Pii.
- Avoid reflecting user identity in responses; if necessary, use opaque identifiers instead of emails or usernames.
- Always serve endpoints over TLS to prevent credential and Pii interception.
- Strip Authorization headers when proxying or caching to prevent unintended exposure.
- Use constant-time checks for credentials and avoid storing secrets in plaintext.
middleBrick can validate that your routes enforce transport security and that responses do not inadvertently expose Pii by scanning the API definition and runtime behavior, surfacing misconfigurations before they reach production.
Related CWEs: dataExposure
| CWE ID | Name | Severity |
|---|---|---|
| CWE-200 | Exposure of Sensitive Information | HIGH |
| CWE-209 | Error Information Disclosure | MEDIUM |
| CWE-213 | Exposure of Sensitive Information Due to Incompatible Policies | HIGH |
| CWE-215 | Insertion of Sensitive Information Into Debugging Code | MEDIUM |
| CWE-312 | Cleartext Storage of Sensitive Information | HIGH |
| CWE-359 | Exposure of Private Personal Information (PII) | HIGH |
| CWE-522 | Insufficiently Protected Credentials | CRITICAL |
| CWE-532 | Insertion of Sensitive Information into Log File | MEDIUM |
| CWE-538 | Insertion of Sensitive Information into Externally-Accessible File | HIGH |
| CWE-540 | Inclusion of Sensitive Information in Source Code | HIGH |