Time Of Check Time Of Use in Buffalo with Bearer Tokens

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 Buffalo, this commonly arises when authorization is verified before an action executes, but the underlying state can change between the check and the use. When combined with Bearer Tokens, the risk pattern shifts to token validity and binding rather than static credentials, but the race condition remains relevant for operations that perform an authorization check and then perform a sensitive action based on request-scoped context.

Consider a Buffalo API endpoint that validates a Bearer Token, confirms scope or role claims, and then proceeds to access or mutate a resource identified by user-supplied input (e.g., /accounts/{id}). A TOCTOU scenario can occur if the token is validated and parsed once at the start of the request, but later logic uses request parameters to determine which resource to act on without re-verifying that the token’s associated subject has the right to that specific resource. An attacker could potentially leverage timing windows — such as concurrent requests or session fixation possibilities — to exploit the gap between check and use. While Buffalo itself does not manage token state, your application’s handling of parsed claims and resource ownership checks can introduce windows where an attacker’s crafted request executes in an inconsistent authorization state.

With Bearer Tokens, the authorization header is typically validated against an issuer, signature, and possibly an introspection or revocation list. If your Buffalo app decodes the token, extracts roles or scopes, and then relies on those values without ensuring the token remains valid and bound to the request context for the entire operation, you create a TOCTOU surface. For example, an endpoint might check that a token contains the role "admin" and then proceed to delete a record identified by an ID supplied by the client. If token validation is not repeated or strongly bound to the operation (for instance, by tying it to the resource owner ID at the moment of use), an attacker could manipulate the ID between the check and the delete, leveraging the initially authorized context to perform unauthorized actions.

Real-world parallels include scenarios where an API validates a token, reads user ID claims, and then performs a database query using client-controlled identifiers without re-asserting that the token’s subject matches the targeted resource. This becomes more pronounced in distributed systems where token introspection or revocation status might lag, and where multiple services exchange requests with bearer context. Although Buffalo does not inherently introduce TOCTOU, patterns common in web APIs — deferred authorization decisions, cached claims, and multi-step workflows — can expose timing-sensitive authorization gaps. Mitigation involves ensuring that every sensitive operation re-validates not only the token’s authenticity but also the subject’s permissions on the specific resource immediately before the action, and avoiding reliance on stale or loosely bound authorization state.

Remediation centers on binding token validation closely to each sensitive operation and avoiding deferred or reused authorization decisions. In Buffalo, you can structure handlers so that token validation and resource ownership checks occur within the same transactional or request context, minimizing timing gaps. Below are concrete code examples demonstrating secure patterns using Bearer Tokens with Buffalo.

Example 1: Immediate validation and ownership check in a single handler

Ensure that for each sensitive operation, you validate the token and verify ownership or permissions right before the action, passing the subject identity directly into the database query.

// handlers/accounts.go
package handlers

import (
    "context"
    "net/http"

    "github.com/gobuffalo/buffalo"
    "github.com/gobuffalo/packr/v2"
    "github.com/golang-jwt/jwt/v5"
    "myapp/models"
)

func GetAccount(c buffalo.Context) error {
    // Assume bearer token is in "Authorization: Bearer <token>"
    auth := c.Request().Header.Get("Authorization")
    if auth == "" {
        return c.Error(http.StatusUnauthorized, errors.New("missing authorization header"))
    }
    const bearerPrefix = "Bearer "
    if len(auth) < len(bearerPrefix) || auth[:len(bearerPrefix)] != bearerPrefix {
        return c.Error(http.StatusUnauthorized, errors.New("invalid authorization header format"))
    }
    tokenString := auth[len(bearerPrefix):]

    // Validate and parse token
    token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
        // Provide your key function or public key here
        return myPublicKey, nil
    })
    if err != nil || !token.Valid {
        return c.Error(http.StatusUnauthorized, errors.New("invalid token"))
    }

    // Extract subject claim (e.g., user ID)
    claims, ok := token.Claims.(jwt.MapClaims)
    if !ok {
        return c.Error(http.StatusUnauthorized, errors.New("invalid claims"))
    }
    subject, ok := claims["sub"]
    if !ok {
        return c.Error(http.StatusUnauthorized, errors.New("missing subject claim"))
    }
    userID, ok := subject.(string)
    if !ok {
        return c.Error(http.StatusBadRequest, errors.New("invalid subject type"))
    }

    // Bind resource identifier to subject immediately
    accountID, ok := c.Params().Get("account_id")
    if !ok {
        return c.Error(http.StatusBadRequest, errors.New("missing account_id"))
    }

    var account models.Account
    // Ownership check in the same context — no deferred decision
    if err := models.Where("id = ? AND user_id = ?", accountID, userID).First(&account); err != nil {
        return c.Error(http.StatusNotFound, errors.New("account not found or access denied"))
    }

    return c.Render(http.StatusOK, r.JSON(account))
}

Example 2: Middleware that enforces token binding and avoids stale claims

Use a Buffalo middleware to validate the token and attach the subject to the context, but ensure downstream handlers still perform resource-level checks immediately before use.

// middleware/auth.go
package middleware

import (
    "net/http"
    "github.com/gobuffalo/buffalo"
    "github.com/golang-jwt/jwt/v5"
)

func AuthRequired(next buffalo.Handler) buffalo.Handler {
    return func(c buffalo.Context) error {
        auth := c.Request().Header.Get("Authorization")
        if auth == "" {
            return c.Error(http.StatusUnauthorized, errors.New("missing authorization header"))
        }
        const bearerPrefix = "Bearer "
        if len(auth) < len(bearerPrefix) || auth[:len(bearerPrefix)] != bearerPrefix {
            return c.Error(http.StatusUnauthorized, errors.New("invalid authorization header format"))
        }
        tokenString := auth[len(bearerPrefix):]

        token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
            return myPublicKey, nil
        })
        if err != nil || !token.Valid {
            return c.Error(http.StatusUnauthorized, errors.New("invalid token"))
        }

        claims, ok := token.Claims.(jwt.MapClaims)
        if !ok {
            return c.Error(http.StatusUnauthorized, errors.New("invalid claims"))
        }
        subject, ok := claims["sub"]
        if !ok {
            return c.Error(http.StatusUnauthorized, errors.New("missing subject claim"))
        }

        // Attach subject to context for downstream use, but handlers must still re-check ownership
        c.Set("subject", subject)
        return next(c)
    }
}

Downstream handler should still bind and verify resource ownership immediately before operating:

// handlers/transfers.go
func PostTransfer(c buffalo.Context) error {
    subject, ok := c.Get("subject")
    if !ok {
        return c.Error(http.StatusUnauthorized, errors.New("unauthorized"))
    }
    userID, ok := subject.(string)
    if !ok {
        return c.Error(http.StatusBadRequest, errors.New("invalid subject type"))
    }

    // Parse and validate request body
    req := struct {
        FromAccountID string `json:"from_account_id"`
        ToAccountID   string `json:"to_account_id"`
        Amount        string `json:"amount"`
    }{}
    if err := c.Bind(&req); err != nil {
        return c.Error(http.StatusBadRequest, err)
    }

    // Immediate ownership and validity checks — no deferred decision
    var fromAccount models.Account
    if err := models.Where("id = ? AND user_id = ?", req.FromAccountID, userID).First(&fromAccount); err != nil {
        return c.Error(http.StatusBadRequest, errors.New("from_account invalid or access denied"))
    }
    var toAccount models.Account
    if err := models.Where("id = ?", req.ToAccountID).First(&toAccount); err != nil {
        return c.Error(http.StatusBadRequest, errors.New("to_account invalid"))
    }

    // Perform transfer logic...
    return c.Render(http.StatusCreated, r.JSON(fromAccount))
}

These patterns ensure that Bearer Token validation and resource authorization are tightly coupled, reducing the TOCTOU window. Always prefer re-validation of permissions on the specific resource immediately before the action, and avoid relying on authorization decisions made earlier in the request lifecycle.