Race Condition in Aspnet with Bearer Tokens

A race condition in an ASP.NET API occurs when the outcome depends on the timing or interleaving of operations, and the use of bearer tokens can inadvertently turn timing differences or missing validations into security-relevant behavior. A concrete example is token validation combined with state-changing logic where two concurrent requests share the same logical identifier (e.g., a resource ID) but operate on an authorization state that has not been made atomic or consistently synchronized.

Consider an endpoint that first validates a bearer token and then checks a per-user resource state in a database. If the validation passes but the state check and the subsequent update are not performed within a consistent transactional or locking boundary, an attacker can issue two parallel requests with the same bearer token and a resource identifier that is being modified. In one typical race, request A reads state S1, request B reads the same S1, request A updates to S2, and request B overwrites with an incorrect S3 because it still operated on S1. Because bearer tokens identify the caller but do not serialize operations on the server, the API may apply updates intended for A while B’s stale read leads to data loss or privilege confusion.

Insecure deserialization or cached authorization decisions can exacerbate this. If authorization results are cached per bearer token without a tight scope and short lifetime, one request may see a cached allow while another concurrent request invalidates that permission, yet both proceed because cache invalidation is not synchronously coordinated. Similarly, when token introspection or claims extraction is performed multiple times within a request pipeline and the underlying claims can change mid-execution (e.g., via an administrative API), the non-atomic composition of checks can yield different outcomes depending on timing.

Race conditions are not theoretical; they map onto OWASP API Top 10 controls such as broken object level authorization (BOLA) and can be triggered in workflows where bearer tokens identify the user but do not enforce strict ordering or atomic checks. Attack patterns include rapid repeated calls that exploit timing windows, or leveraging asynchronous code paths where awaits reorder logic in non-thread-safe manners. Real-world CVEs in related frameworks often involve missing database transactions or lack of optimistic concurrency tokens when state is updated after claims validation.

Remediation focuses on making authorization decisions atomic with respect to the operation, avoiding reliance on timing-sensitive caches, and ensuring that bearer token identity is combined with concurrency controls.

• Use transactions or optimistic concurrency for state changes. With Entity Framework Core, for example, wrap the read–modify–write sequence in a transaction or use a concurrency token (row version) so that concurrent updates fail safely and the client must retry.
• Perform authorization as close as possible to the data operation and keep the token validation and permission check within the same logical unit of work. Avoid caching authorization results that can become stale within a user’s request window; if caching is required, scope it tightly and tie invalidation to the specific resource version.
• Structure endpoint logic so that claims extraction, policy evaluation, and database updates form a single, coherent step. Prefer the built-in authorization mechanisms that evaluate policies with the current user and current resource, rather than manually checking claims across separate steps.

Code examples for an ASP.NET Core API using bearer tokens:

// Example 1: Atomic check with EF Core concurrency token
[ApiController]
[Route("api/items")]
public class ItemsController : ControllerBase
{
    private readonly AppDbContext _db;
    public ItemsController(AppDbContext db) => _db = db;

    [HttpPut("{id}")]
    [Authorize] // bearer token required
    public async Task UpdateItem(Guid id, UpdateItemDto dto)
    {
        // Fetch within the request lifetime; no separate auth cache
        var item = await _db.Items.FindAsync(id);
        if (item == null) return NotFound();

        // Apply change with concurrency token; EF will throw DbUpdateConcurrencyException
        item.Property = dto.Property;
        item.Version = dto.ExpectedVersion; // concurrency token
        try
        {
            await _db.SaveChangesAsync();
        }
        catch (DbUpdateConcurrencyException)
        {
            // Conflict: requeue or return 409
            return Conflict(new { Message = "Resource was modified concurrently." });
        }
        return NoContent();
    }
}

// Example 2: Policy-based authorization with resource-based requirements
services.AddAuthorization(options =>
{
    options.AddPolicy("CanModifyItem", policy =>
        policy.RequireAssertion(context =>
        {
            var itemId = context.Resource?.GetType().GetProperty("ItemId")?.GetValue(context.Resource) as Guid?;
            if (!itemId.HasValue) return false;
            // fetch current owner from DB within the assertion, keeping it atomic with the operation
            // In practice, use a service scoped within the assertion that reads the latest state
            return ItemBelongsToUser(itemId.Value, context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value);
        }));
});

[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    private readonly AppDbContext _db;
    public OrdersController(AppDbContext db) => _db = db;

    [HttpPatch("{id}")]
    [Authorize(Policy = "CanModifyItem")]
    public async Task ModifyOrder(Guid id, PatchOrderDto dto)
    {
        var order = await _db.Orders
            .Include(o => o.Items)
            .FirstOrDefaultAsync(o => o.Id == id);
        if (order == null) return NotFound();

        // Apply modifications
        // Concurrency handled via EF or explicit version check
        await _db.SaveChangesAsync();
        return NoContent();
    }
}

In these patterns, bearer tokens are used to identify the user via standard authentication middleware, while the critical step is coupling identity to resource state checks inside the same atomic operation (transaction or concurrency token). This reduces the window for race conditions and ensures that timing differences do not lead to authorization bypass or data corruption.