Time Of Check Time Of Use in Chi with Mutual Tls

Time Of Check Time Of Use (TOCTOU) in Chi with Mutual TLS involves a race condition where the state of a resource is verified (checked) at an earlier point, but the actual use of that resource occurs later, allowing the state to change between the check and the use. When Mutual TLS is used, the client and server authenticate each other with certificates, and authorization decisions are often made after validating the client certificate. A common pattern is to check certificate validity, roles, or permissions, and then process a request. If the authorization check and the subsequent action are not atomic, an attacker can manipulate the context between the check and the use.

In Chi, a typical flow might involve verifying the client certificate, looking up associated permissions (e.g., from a database or in-memory store), and then routing to a handler that performs an operation such as reading or modifying a resource. An attacker could cause the underlying data to change between the permission check and the operation. For example, a user might be authorized to access resource A at the time of check, but before the handler reads resource A, an admin revokes access or the resource is reassigned. Because the check was performed over HTTPS with Mutual TLS, the identity is trusted, but the authorization logic remains vulnerable to TOCTOU if it is not consistently enforced at the point of use.

Mutual TLS ensures that both parties are authenticated, but it does not guarantee that authorization decisions remain valid through the entire request lifecycle. In Chi, developers might rely on middleware that performs a one-time check and then passes the request to downstream handlers. If those handlers do not re-validate permissions or if shared state (such as a cache of roles) is mutable, the window for exploitation exists. This is particularly relevant for operations that involve multiple steps or asynchronous processing, where the initial check and the eventual use are separated in time and potentially in execution context.

Consider a scenario where a Chi handler checks a certificate’s organizational unit to determine access to a user profile, then retrieves the profile from a store. An attacker with a valid certificate could trigger changes to that profile between the check and the retrieval, such as modifying the profile’s ownership or permissions in the backing data store. Because the check was based on a snapshot of state, the use of the profile proceeds under stale assumptions. TOCTOU in this context does not break the TLS layer but exploits the gap in authorization continuity. This underscores the need to embed authorization validation as close as possible to the operation, ideally within the same transaction or execution context, to prevent timing-based privilege escalation.

To mitigate TOCTOU in Chi with Mutual TLS, ensure that authorization checks are performed atomically with the operation they guard, and avoid relying on stale state. Re-validate permissions at the point of use, and design handlers to be idempotent and self-contained. Below are concrete code examples demonstrating secure patterns.

First, a secure handler that performs authorization within the same function, using the certificate information extracted from the request context. This avoids splitting check and use across different layers or goroutines where state could change.

package main

import (
    "context"
    "net/http"

    "github.com/go-chi/chi/v5"
    "github.com/go-chi/chi/v5/middleware"
)

type AuthContextKey string

const (
    CertSubjectKey AuthContextKey = "cert_subject"
)

func main() {
    r := chi.NewRouter()
    r.Use(middleware.RequestID)
    r.Use(middleware.RealIP)
    r.Use(middleware.Secure)
    r.Use(middleware.Recoverer)

    // Mutual TLS enforced upstream by the server configuration.
    // The subject is extracted and placed into the request context for authorization.
    r.Use(func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            // In a real deployment, the certificate subject would be extracted
            // from the TLS connection state provided by the server.
            subject := r.Header.Get("X-SSL-Client-Subject") // Example header set by the TLS layer
            ctx := context.WithValue(r.Context(), CertSubjectKey, subject)
            next.ServeHTTP(w, r.WithContext(ctx))
        })
    })

    r.Get("/profile/{username}", func(w http.ResponseWriter, r *http.Request) {
        subject := r.Context().Value(CertSubjectKey).(string)
        username := chi.URLParam(r, "username")

        // Atomic authorization and data access: check and use happen in the same scope.
        if !isAllowed(subject, username) {
            http.Error(w, "forbidden", http.StatusForbidden)
            return
        }

        profile, err := getUserProfile(username)
        if err != nil {
            http.Error(w, "not found", http.StatusNotFound)
            return
        }

        // Proceed with the operation, knowing authorization was verified moments before.
        _ = profile
        w.WriteHeader(http.StatusOK)
    })
}

func isAllowed(certSubject, targetUsername string) bool {
    // Implement your policy: e.g., certSubject must map to targetUsername.
    // This check is performed immediately before the operation, minimizing TOCTOU risk.
    return certSubject == "CN="+targetUsername
}

func getUserProfile(username string) (interface{}, error) {
    // Simulated data access.
    return map[string]string{"username": username}, nil
}

Second, for scenarios where permissions are stored externally and may change, re-fetch and verify immediately before the operation. Do not cache authorization decisions across requests or goroutines.

func (h *Handler) UpdateUserSettings(w http.ResponseWriter, r *http.Request) {
    subject := r.Context().Value(CertSubjectKey).(string)
    settingsID := chi.URLParam(r, "id")

    // Re-validate right before use to avoid TOCTOU.
    if !h.authService.CanModify(subject, settingsID) {
        http.Error(w, "forbidden", http.StatusForbidden)
        return
    }

    // Perform the update within the same transactional context if applicable.
    if err := h.store.UpdateSettings(settingsID, subject, r.Body); err != nil {
        http.Error(w, "error", http.StatusInternalServerError)
        return
    }

    w.WriteHeader(http.StatusOK)
}

These patterns emphasize that Mutual TLS provides strong client authentication, but authorization must be enforced close to the operation to prevent TOCTOU. In Chi, this means embedding checks directly in handlers or within tightly scoped service calls, avoiding deferred or separated validation steps that rely on mutable external state.