Time Of Check Time Of Use in Chi with Basic Auth

Time Of Check Time Of Use (TOCTOU) is a class of race condition that occurs when the outcome of a security decision depends on the timing between a check and the subsequent use of a resource. In Chi, this typically manifests when an authorization check (e.g., verifying credentials or permissions) and the actual resource access are not performed as a single, atomic operation. When combined with HTTP Basic Authentication, the risk profile changes in subtle ways that can bypass intended protections.

Consider a Chi handler that first validates a Basic Auth credential set (username and password) and, after a successful check, proceeds to access a protected resource such as a user record or a file path. The check might look up the user in a repository or verify a hashed password. However, if the handler does not carry the authorization state forward atomically, an attacker can manipulate the window between the check and the use. For example, an authenticated request may pass the initial credential validation, but before the handler uses the identity to query a database, the attacker can alter the request context — such as changing the URL path, query parameters, or even the effective user by exploiting shared mutable state in a concurrent environment.

Basic Authentication exacerbates this because the credentials are transmitted with each request and are often decoded and validated independently of any session or token. In Chi, if the framework or middleware decodes the Authorization header, performs a check (e.g., does this user have permission to access /resources/{id}?), and then later uses the decoded identity in a non-atomic sequence, the identity can be subtly altered between those steps. This is especially dangerous when the identifier used after the check is derived from user input (e.g., a path parameter) rather than from the validated credential context. An attacker could leverage symbolic link traversal, insecure direct object references (IDOR), or race conditions in backend storage to access data belonging to another user, despite the initial check appearing to succeed.

With OpenAPI/Swagger spec analysis, tools like middleBrick can detect mismatches between declared authentication requirements and runtime behavior, highlighting endpoints where authorization checks are not tightly coupled with resource access. The scanner can surface endpoints that accept Basic Auth but then perform indirect object references without re-verifying scope or context, which is a common precursor to IDOR and BOLA vulnerabilities under the TOCTOU pattern. Because Basic Auth does not inherently bind a session or token to a secure context, the onus is on the application to ensure that the identity used in the check is the same identity used in the subsequent operation, and that no mutable external state can intervene.

Real-world attack patterns include an endpoint that verifies a user’s role via Basic Auth, then constructs a file path using an attacker-controlled identifier. Between the role check and the file open operation, an attacker may manipulate the identifier to traverse directories if the application does not canonicalize paths or enforce ownership strictly. Another pattern involves database queries where the user ID is checked and then used in a separate query; if the user can influence the second query’s parameters between the check and execution, data leakage occurs. middleBrick’s LLM/AI Security and Input Validation checks are designed to surface these risky sequences by correlating authentication mechanisms with object references and data flows.

To mitigate TOCTOU in Chi when using Basic Authentication, ensure that authorization checks and resource usage are performed atomically and that the identity derived from credentials is bound to the operation without mutable intermediate state. Avoid performing a check and then later using a separate, user-supplied identifier to access resources. Instead, derive all necessary context from the validated credential and enforce strict scoping at the point of use.

Below are concrete Chi code examples demonstrating secure patterns.

Example 1: Atomic authorization with bound identity

Decode and validate credentials once, then immediately use the identity to construct a safe resource query. Do not re-derive the resource identifier from external input after validation.

// Chi middleware that validates Basic Auth and binds identity to the request context
import "github.com/go-chi/chi/v5"
import "encoding/base64"
import "strings"

func BasicAuthMiddleware(next chi.Handler) chi.Handler {
    return chi.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        auth := r.Header.Get("Authorization")
        if auth == "" || !strings.HasPrefix(auth, "Basic ") {
            http.Error(w, "Unauthorized", 401)
            return
        }
        payload, err := base64.StdEncoding.DecodeString(strings.TrimPrefix(auth, "Basic "))
        if err != nil {
            http.Error(w, "Unauthorized", 401)
            return
        }
        pair := strings.SplitN(string(payload), ":", 2)
        if len(pair) != 2 {
            http.Error(w, "Unauthorized", 401)
            return
        }
        username, password := pair[0], pair[1]
        // Validate credentials against a data source (e.g., hashed password check)
        if !isValidUser(username, password) {
            http.Error(w, "Forbidden", 403)
            return
        }
        // Attach a minimal, trusted identity to the context — do not accept user-supplied IDs later
        ctx := context.WithValue(r.Context(), "identity", username)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

// Handler that uses the bound identity directly
func GetResourceHandler(w http.ResponseWriter, r *http.Request) {
    identity, ok := r.Context().Value("identity").(string)
    if !ok {
        http.Error(w, "Forbidden", 403)
        return
    }
    // Use identity to fetch resource, avoiding user-controlled identifiers
    resourceID := chi.URLParam(r, "resource_id")
    // Ensure resourceID is validated and scoped to identity (e.g., check ownership in DB)
    resource, err := fetchResource(identity, resourceID)
    if err != nil || resource == nil {
        http.Error(w, "Not Found", 404)
        return
    }
    w.Write([]byte(fmt.Sprintf("Resource: %s", resource.Data)))
}

func isValidUser(username, password string) bool {
    // Implement secure password verification (e.g., bcrypt)
    return true // placeholder
}

func fetchResource(username, resourceID string) (*Resource, error) {
    // Query database with both username and resourceID to enforce ownership
    return &Resource{Data: "safe_data"}, nil
}

Example 2: Avoiding indirect object references after check

Do not perform an authorization check and then use a separate user-controlled ID to locate a record. Instead, bind the user identity to the query so the database enforces scope.

// Unsafe pattern to avoid:
// 1. Check user role
// 2. Use userID from query param to fetch data
// This enables IDOR if userID is manipulated between check and use.

// Secure alternative: embed identity in the query predicate
func GetUserProfileHandler(w http.ResponseWriter, r *http.Request) {
    auth := r.Header.Get("Authorization")
    // ... decode and validate Basic Auth as above
    identity := "trusted_user" // derived from auth, not from URL
    // Assume chi.URLParam(r, "user_id") is not trusted for scoping
    profile, err := dbGetProfileByOwner(r.Context(), identity, chi.URLParam(r, "user_id"))
    if err != nil {
        http.Error(w, "Forbidden or not found", 404)
        return
    }
    w.Write(profile)
}

func dbGetProfileByOwner(ctx context.Context, owner, requestedID string) (*Profile, error) {
    // SQL: SELECT * FROM profiles WHERE owner = $1 AND id = $2
    // This ensures the record returned belongs to the authenticated owner
    return &Profile{}, nil
}

These patterns enforce that the identity used after authentication is derived from the validated credentials and is not re-discoverable or mutable via external input between the check and the use. This reduces the TOCTOU window and limits the impact of IDOR and BOLA risks when Basic Authentication is employed.