Data Exposure in Chi with Jwt Tokens
Data Exposure in Chi with Jwt Tokens — how this specific combination creates or exposes the vulnerability
The Data Exposure check in middleBrick examines how APIs handle sensitive information, including JSON Web Tokens (JWTs). In Chi, a common pattern is to store a JWT in a cookie or send it in an Authorization header. When APIs in Chi inadvertently expose JWTs—such as logging them, returning them in error responses, or failing to restrict access to token introspection endpoints—these tokens can be leaked to unauthorized parties. This can occur when developers embed JWTs in URLs, fail to use secure and httpOnly cookie flags, or transmit tokens over non-encrypted channels (missing TLS). MiddleBrick’s Data Exposure checks look for these patterns and flag configurations where JWTs might be read or intercepted.
JWTs are often used for stateless authentication in Chi-based services. If an endpoint returns a JWT in a response body without proper access controls, or if debug endpoints echo the token, the token value may be exposed in logs, browser histories, or network traces. MiddleBrick scans for these exposures by observing runtime responses and comparing them against the declared OpenAPI schema. For example, an OpenAPI spec that defines a /user/profile endpoint returning a JWT in a JSON field without marking it as sensitive in the schema can lead to accidental leakage. MiddleBrick cross-references the spec with observed responses to detect mismatches where tokens appear in places they should not.
Another exposure vector involves introspection or revocation endpoints. If these endpoints in Chi are unauthenticated or weakly protected, an attacker could enumerate valid JWTs or learn token metadata. MiddleBrick tests whether token-related endpoints require authentication and whether they expose tokens in URLs or logs. Additionally, tokens stored in local storage or passed in query strings increase the risk of exposure through referrer headers or browser plugins. The scanner checks for tokens in query parameters and flags endpoints that accept JWTs via GET requests, which are more likely to be logged by servers or proxies.
Encryption and transport security are also evaluated. MiddleBrick verifies that all token transmissions occur over TLS and that sensitive headers are not stripped by intermediaries. A Chi application that issues JWTs over HTTP, or that sets cookies without the Secure attribute, will be flagged. The scanner also reviews response headers to ensure tokens are not included in error messages or stack traces, which can happen when frameworks expose internal details in development mode. By aligning these runtime observations with the OpenAPI spec, middleBrick provides findings that highlight exactly where JWT exposure occurs in Chi deployments.
Finally, the scanner considers the broader API surface. If an API in Chi returns JWTs as part of an inventory or logging endpoint, or if tokens are included in metadata responses, the risk of data exposure increases. MiddleBrick’s Data Exposure checks map these findings to frameworks such as OWASP API Top 10 and highlight the need to treat JWTs as sensitive secrets. The goal is not to fix but to report with remediation guidance, helping teams in Chi adjust configurations, revise OpenAPI definitions, and ensure tokens are handled securely throughout the request lifecycle.
Jwt Tokens-Specific Remediation in Chi — concrete code fixes
To remediate JWT-related data exposure in Chi, ensure tokens are never logged, returned inappropriately, or transmitted insecurely. Use secure cookie attributes and avoid embedding JWTs in URLs. Below are concrete examples for handling JWTs safely in Chi applications.
Example 1: Setting Secure JWT Cookies in Chi
When using Chi’s cookie utilities, set the Secure, HttpOnly, and SameSite attributes to reduce exposure:
// Chi cookie example for JWT storage
import "github.com/go-chi/chi/v5/middleware"
import "net/http"
func setTokenCookie(w http.ResponseWriter, token string) {
http.SetCookie(w, &http.Cookie{
Name: "access_token",
Value: token,
HttpOnly: true,
Secure: true, // requires HTTPS
SameSite: http.SameSiteStrictMode,
Path: "/",
MaxAge: 3600,
})
}
Example 2: Returning JWTs in JSON Response Headers Only
If you must return a JWT, place it in a custom header and ensure it is not echoed in the body or logs:
// Chi route returning JWT in a header
import "github.com/go-chi/chi/v5"
import "net/http"
func loginHandler(w http.ResponseWriter, r *http.Request) {
token := "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." // issued token
w.Header().Set("X-Access-Token", token)
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusOK)
// Write minimal response without exposing the token in the body
w.Write([]byte(`{"message":"authenticated"}`))
}
Example 3: Protecting Introspection Endpoints
Ensure token introspection endpoints require authentication and do not leak token values in responses:
// Chi middleware to protect introspection
import "net/http"
func requireAuth(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
token := r.Header.Get("Authorization")
if token == "" {
http.Error(w, `{"error":"unauthorized"}`, http.StatusUnauthorized)
return
}
// Validate token before proceeding
next.ServeHTTP(w, r)
})
}
func introspectHandler(w http.ResponseWriter, r *http.Request) {
// Perform introspection without returning the raw JWT
w.Header().Set("Content-Type", "application/json")
w.Write([]byte(`{"active":true}`))
}
Example 4: Avoiding JWT in URLs and Logs
Never log JWTs or pass them in query strings. Use headers instead:
// Chi middleware to avoid logging tokens
import "log"
import "net/http"
func noTokenLogging(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// Strip token from logs; do not print Authorization header
req := r.Clone(r.Context)
req.Header.Del("Authorization")
log.Printf("request: %s %s", req.Method, req.URL.Path)
next.ServeHTTP(w, r)
})
}
Example 5: Enforcing TLS for Token Transmission
Ensure all token transmissions occur over HTTPS by using Chi’s TLS middleware:
// Chi TLS enforcement
import "github.com/go-chi/chi/v5"
import "net/http"
func main() {
r := chi.NewRouter()
// Enforce secure cookies and TLS in production
r.Use(middleware.Secure)
r.Get("/protected", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte(`{"secure":true}`))
})
http.ListenAndServeTLS(":443", "server.crt", "server.key", r)
}
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 |