Race Condition in Gin with Basic Auth

A race condition in Gin when Basic Authentication is used typically arises when authorization checks and state mutation are not performed atomically within a request. Consider an endpoint that first verifies a Basic Auth credential, then reads and updates a mutable in-memory counter or shared resource (for example, remaining request credits). If two concurrent requests pass authentication and both read the same initial counter value before either writes back the decremented value, the final state may incorrectly allow more requests than intended. This is a classic time‑of‑check-to-time‑of-use (TOCTOU) pattern in a concurrent server runtime, where the window between read and write is exploitable.

Gin’s default behavior is to handle each request in a separate goroutine. If you store per‑user or per‑client state in package‑level variables or in a shared map without synchronization, concurrent requests can interfere. For example, an attacker could open many connections using the same Basic Auth credentials and trigger the authorization branch in parallel, potentially bypassing rate‑limit or quota logic that relies on that shared state. MiddleBrick’s checks for BOLA/IDOR and BFLA/Privilege Escalation include this scenario, because the authorization boundary is effectively weakened when concurrency exposes timing differences between verification and state update.

Another relevant pattern is when the Basic Auth validation is performed once and the resulting identity is placed into a Gin context value, then later handlers assume the value is consistent across middleware and route handlers. If a middleware mutates shared data associated with that identity without locks or atomic operations, a race can allow one request to see another request’s intermediate state. For instance, a handler might decrement a per‑user quota and another handler might read that quota to decide whether to allow an administrative action; interleaving these operations can lead to privilege escalation or unauthorized operations, which map to Property Authorization and BFLA findings in the 12 checks.

In real-world terms, this does not mean Gin or Basic Auth are broken by design, but that the surrounding logic must guarantee atomicity and visibility across goroutines. The vulnerability is not about credentials leaking, but about the correctness of shared state management when authentication has already occurred. Proper remediation therefore focuses on synchronization and on ensuring that authorization and state changes are performed as a single, isolated operation.

To eliminate race conditions when using Basic Authentication in Gin, ensure shared state is accessed atomically and that authorization checks and state updates are performed in a thread‑safe manner. Below are concrete, idiomatic examples you can apply directly in your Gin routes.

1) Use sync.Mutex to guard shared state. If you maintain a map of usernames to remaining request credits, protect all reads and writes with a mutex so that concurrent requests cannot observe inconsistent values.

import (
    "net/http"
    "sync"

    "github.com/gin-gonic/gin"
)

type AccountState struct {
    mu      sync.Mutex
    credits map[string]int // username -> remaining credits
}

var state = AccountState{credits: map[string]int{"alice": 10}}

func authBasic() gin.HandlerFunc {
    return func(c *gin.Context) {
        user, pass, ok := c.Request.BasicAuth()
        if !ok || pass != "secret" {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "invalid credentials"})
            return
        }
        c.Set("user", user)
        c.Next()
    }
}

func consumeCredit() gin.HandlerFunc {
    return func(c *gin.Context) {
        user, _ := c.Get("user")
        username := user.(string)

        state.mu.Lock()
        defer state.mu.Unlock()

        if credits, exists := state.credits[username]; !exists || credits <= 0 {
            c.AbortWithStatusJSON(http.StatusForbidden, gin.H{"error": "no credits"})
            return
        }
        state.credits[username]--
        c.Next()
    }
}

func main() {
    r := gin.Default()
    r.Use(authBasic())
    r.GET(/api/resource, consumeCredit(), func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{"status": "ok"})
    })
    r.Run()
}

2) Prefer sync/atomic for simple counters to avoid locking overhead when only an integer needs to be updated safely. This is appropriate for global rate‑limit style counters tied to a credential.

import (
    "net/http"
    "sync/atomic"

    "github.com/gin-gonic/gin"
)

var creditsLeft int64 = 100

func authAndCheckAtomic() gin.HandlerFunc {
    return func(c *gin.Context) {
        user, pass, ok := c.Request.BasicAuth()
        if !ok || pass != "secret" {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "invalid credentials"})
            return
        }
        // Atomically decrement if positive; if it goes negative, roll back and deny.
        for {
            old := atomic.LoadInt64(&creditsLeft)
            if old <= 0 {
                c.AbortWithStatusJSON(http.StatusForbidden, gin.H{"error": "no credits"})
                return
            }
            if atomic.CompareAndSwapInt64(&creditsLeft, old, old-1) {
                break
            }
        }
        c.Next()
    }
}

func main() {
    r := gin.Default()
    r.Use(authAndCheckAtomic())
    r.GET(/api/resource, func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{"remaining": creditsLeft})
    })
    r.Run()
}

3) For per‑user state, prefer a concurrent map or sharded locks rather than a single global mutex to reduce contention. The example below uses a sharded lock approach to protect per‑username updates while keeping concurrency high.

import (
    "hash/fnv"
    "net/http"
    "sync"

    "github.com/gin-gonic/gin"
)

type shard struct {
    sync.Mutex
    credits map[string]int
}

const shardCount = 16
var shards [shardCount]shard

func shardOf(user string) *shard {
    h := fnv.New32a()
    h.Write([]byte(user))
    return &shards[uint32(h.Sum32())%shardCount]
}

func authBasicSetUser() gin.HandlerFunc {
    return func(c *gin.Context) {
        user, pass, ok := c.Request.BasicAuth()
        if !ok || pass != "secret" {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "invalid credentials"})
            return
        }
        c.Set("user", user)
        c.Next()
    }
}

func consumeCreditSharded() gin.HandlerFunc {
    return func(c *gin.Context) {
        user, _ := c.Get("user")
        username := user.(string)
        s := shardOf(username)

        s.Lock()
        defer s.Unlock()
        if credits, exists := s.credits[username]; !exists || credits <= 0 {
            c.AbortWithStatusJSON(http.StatusForbidden, gin.H{"error": "no credits"})
            return
        }
        s.credits[username]--
        c.Next()
    }
}

func main() {
    // Initialize credits per user
    for _, s := range shards[:] {
        s.credits = make(map[string]int)
    }
    shards[0].credits["alice"] = 10

    r := gin.Default()
    r.Use(authBasicSetUser())
    r.GET(/api/resource, consumeCreditSharded(), func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{"status": "ok"})
    })
    r.Run()
}

These patterns ensure that the authorization check and any associated state updates occur without interference across goroutines, directly addressing the race condition class of issues under BFLA/Privilege Escalation and Property Authorization checks.