Race Condition in Gin with Bearer Tokens

A race condition in a Gin-based service using Bearer tokens typically arises when token validation and stateful business logic are not synchronized, allowing an attacker to exploit timing differences between concurrent requests. Consider a scenario where token validity is checked and then a user role or permissions state is read from a mutable in-memory structure or a cache that can be altered by another request. If two requests with the same Bearer token arrive concurrently—one that performs a state mutation (such as revocation or role change) and one that authorizes a sensitive action—validation may pass for both because the check occurs before the state update completes.

For example, a token might be validated against a local cache or a claims extraction that does not re-query the authoritative data store on each call. An attacker could send a rapid sequence: a request to change their role or permissions and a second request that uses the same Bearer token to access a privileged endpoint immediately after. Due to the lack of atomicity between validation and authorization, the second request might be processed with the old permissions, effectively bypassing intended access controls. This is not a flaw in the Bearer token format itself but in how token-state interactions are managed in a concurrent environment.

In Gin, this can manifest when middleware performs token validation and sets claims in the context, and downstream handlers assume those claims remain constant for the lifetime of the request without re-verifying critical decisions. If token revocation or permission changes are handled via an external system (e.g., a database or a distributed cache) and Gin’s context is populated once per request, concurrent mutations may not be visible to in-flight requests. Additionally, if token invalidation relies on short-lived tokens plus a denylist checked inconsistently, an attacker might reuse a token for a brief window where the denylist update has not propagated across all service instances, creating a time-of-check to time-of-use (TOCTOU) window.

Real-world patterns that can lead to issues include using non-atomic operations on shared state (such as a map of revoked tokens) without proper synchronization, or relying on cached claims across multiple handler functions in the Gin chain. For instance, a handler might decode a token, attach user information to the Gin context, and later authorization logic reads that context without confirming that the token has not been revoked in the interim. An attacker leveraging concurrency can time requests to exploit these windows, especially in high-throughput services where request interleaving is common.

To identify such issues during scanning, tools like middleBrick test for inconsistent authorization checks and unauthenticated endpoint exposure, including LLM-specific risks that could reveal token handling logic. In an API spec, endpoints that accept Bearer tokens in the Authorization header should be analyzed for idempotency and state dependencies. For example, an OpenAPI definition might include security schemes like:

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT
security:
  - bearerAuth: []

Runtime testing can then probe whether concurrent requests with the same token produce different authorization outcomes, indicating a potential race condition. Remediation involves ensuring that authorization decisions are based on fresh, authoritative checks and that state changes affecting token validity are synchronized and visible across all request paths.

To mitigate race conditions with Bearer tokens in Gin, design token validation and authorization to be atomic and idempotent. Avoid relying on mutable in-memory state for authorization decisions; instead, validate each request against a consistent, authoritative source. Below are concrete code examples demonstrating secure patterns.

Example 1: Stateless JWT validation on each request

Use a middleware that verifies the token signature and extracts claims every time, without caching authorization decisions in the context beyond what is necessary. This ensures that revocation or role changes are respected on subsequent requests.

func AuthMiddleware(jwtKey []byte) gin.HandlerFunc {
    return func(c *gin.Context) {
        authHeader := c.GetHeader("Authorization")
        if authHeader == "" {
            c.AbortWithStatusJSON(401, gin.H{"error": "authorization header required"})
            return
        }
        // Bearer <token> format
        parts := strings.Split(authHeader, " ")
        if len(parts) != 2 || parts[0] != "Bearer" {
            c.AbortWithStatusJSON(401, gin.H{"error": "invalid authorization format"})
            return
        }
        tokenString := parts[1]
        claims := &CustomClaims{}
        token, err := jwt.ParseWithClaims(tokenString, claims, func(token *jwt.Token) (interface{}, error) {
            return jwtKey, nil
        })
        if err != nil || !token.Valid {
            c.AbortWithStatusJSON(401, gin.H{"error": "invalid token"})
            return
        }
        // Attach minimal, verified data; avoid long-lived mutable state
        c.Set("userID", claims.UserID)
        c.Set("roles", claims.Roles)
        c.Next()
    }
}

Example 2: Authorization check with fresh data per request

For endpoints that require strict authorization, re-check critical permissions inside the handler using the token claims and an up-to-date data source. This avoids stale context values leading to privilege escalation.

func TransferHandler(c *gin.Context) {
    userID, exists := c.Get("userID")
    if !exists {
        c.AbortWithStatusJSON(401, gin.H{"error": "unauthorized"})
        return
    }
    var req TransferRequest
    if err := c.ShouldBindJSON(&req); err != nil {
        c.AbortWithStatusJSON(400, gin.H{"error": "invalid request"})
        return
    }
    // Re-verify permissions against a database or service
    hasPermission := checkPermission(userID.(string), req.AccountID)
    if !hasPermission {
        c.AbortWithStatusJSON(403, gin.H{"error": "forbidden"})
        return
    }
    // Proceed with transfer
    c.JSON(200, gin.H{"status": "ok"})
}

Example 3: Avoid shared mutable token denylist without synchronization

If maintaining a denylist, use synchronization primitives or external stores with atomic operations rather than plain maps. For simplicity, this example uses an external cache with TTL to ensure visibility and avoid race conditions across goroutines.

var ( 
    tokenDenylist = make(map[string]time.Time)
    denylistMu    sync.RWMutex
)
func IsTokenRevoked(tokenID string) bool {
    denylistMu.RLock()
    exp, found := tokenDenylist[tokenID]
    denylistMu.RUnlock()
    return found && time.Now().Before(exp)
}
func RevokeToken(tokenID string, duration time.Duration) {
    denylistMu.Lock()
    defer denylistMu.Unlock()
    tokenDenylist[tokenID] = time.Now().Add(duration)
}
// In middleware
if IsTokenRevoked(claims.JTI) {
    c.AbortWithStatusJSON(401, gin.H{"error": "token revoked"})
    return
}

These patterns emphasize that Bearer token security in Gin depends on consistent validation, minimal shared state, and fresh authorization checks. Combine these practices with automated scanning using tools like middleBrick to detect timing-related authorization inconsistencies and ensure compliance with frameworks such as OWASP API Top 10.