Credential Stuffing in Aspnet with Bearer Tokens

Credential stuffing in an ASP.NET context with Bearer tokens occurs when an attacker uses previously breached username and password pairs to sign in and then leverages the resulting access tokens—typically issued as Bearer tokens—to access protected API endpoints. Unlike brute-force attacks, credential stuffing relies on the reuse of credentials across multiple services. If an ASP.NET application issues Bearer tokens after validating user credentials but does not adequately validate the token on each request or tie the token tightly to the authentication context, an attacker can reuse captured tokens across user accounts or sessions.

The vulnerability surface expands when token issuance does not adequately bind the token to a specific scope, origin, or session. For example, an endpoint that accepts a Bearer token in the Authorization header but does not enforce strict referrer checks or validate the token’s associated permissions can allow horizontal privilege escalation. In ASP.NET applications that use cookie-based authentication alongside token-based flows, misconfiguration can enable token substitution or token replay if anti-forgery measures are absent. Attackers may also exploit weak rate limiting or lack of device fingerprinting, enabling automated credential submission and token harvesting without triggering defenses.

Consider an ASP.NET Core Web API that authenticates via a token endpoint and returns a Bearer token without binding it to the client’s IP or user-agent. An attacker who obtains a valid token from a breached credential pair can replay it from a different location to enumerate user data or perform actions on behalf of the victim. If the API relies solely on token presence and does not cross-check token usage patterns or enforce per-request authorization, this becomes a pathway for unauthorized data access. The combination of reused credentials and permissive token handling creates a chain where initial compromise leads to broader account or lateral movement within the application.

Remediation focuses on reducing token misuse by binding tokens to context, tightening validation, and enforcing strict authorization. Below are concrete code examples for ASP.NET Core that demonstrate secure token issuance and validation practices.

First, configure token-based authentication with explicit options that avoid overly permissive acceptance. The following example sets Bearer token validation to check the audience and issuer, and disables automatic authentication for endpoints that do not require it:

// Program.cs or Startup.cs
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;
using System.Text;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidIssuer = "https://your-issuer.example.com",
        ValidateAudience = true,
        ValidAudience = "https://your-audience.example.com",
        ValidateLifetime = true,
        ClockSkew = TimeSpan.FromMinutes(2),
        ValidateIssuerSigningKey = true,
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("your-very-secure-key-here-keep-this-secret"))
    };
    options.RequireHttpsMetadata = true;
});

var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();
app.Run();

Second, bind tokens to additional claims such as scopes and session identifiers, and enforce authorization at the endpoint or policy level. This helps prevent token reuse across different permission contexts:

// Example policy-based authorization in a controller
[ApiController]
[Route("api/[controller]")]
public class DataController : ControllerBase
{
    [HttpGet("{id}")]
    [Authorize(Policy = "RequireDataScope")]
    public IActionResult Get(int id)
    {
        // Token must include scope claim for data:read
        var scope = User.FindFirst("scope")?.Value;
        if (!scope.Contains("data:read"))
        {
            return Forbid();
        }
        // Proceed with data retrieval
        return Ok(new { Data = "sensitive" });
    }
}

// In Program.cs, define the policy
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("RequireDataScope", policy =>
        policy.RequireAssertion(context =>
            context.User.HasClaim(c => c.Type == "scope" && c.Value.Contains("data:read"))));
});

Third, mitigate replay and token substitution by correlating requests with a nonce or session identifier when feasible, and enforce strict HTTP security headers and referrer checks at the middleware level. Additionally, apply rate limiting to token validation endpoints to reduce automated submission success:

// Use ASP.NET Core rate limiting (requires Microsoft.AspNetCore.RateLimiting)
builder.Services.AddRateLimiter(options =>
{
    options.AddPolicy("TokenEndpointPolicy", context =>
        RateLimitPartition.GetFixedWindowLimiter(
            partitionKey: context.User.Identity?.Name ?? context.Request.Headers["Authorization"].ToString(),
            factory: _ => new FixedWindowRateLimiterOptions
            {
                AutoReplenishment = true,
                PermitLimit = 5,
                Window = TimeSpan.FromSeconds(30)
            }));
});

app.UseRateLimiter();

Finally, ensure that token revocation and short lifetimes are used in combination with refresh token rotation, and that tokens include a `jti` (JWT ID) claim for tracking. This reduces the window during which a stolen Bearer token remains useful in a credential stuffing scenario.