Auth Bypass in Aspnet with Bearer Tokens

In ASP.NET applications, using Bearer tokens relies on the framework to validate the presence and correctness of the token in the Authorization header. An auth bypass can occur when the pipeline does not enforce authentication for all protected endpoints or when the token validation logic is incomplete. For example, if an endpoint is allowed for anonymous access (e.g., via [AllowAnonymous] or missing [Authorize]) or if the authentication scheme is misconfigured, an attacker can send requests with a missing, malformed, or arbitrary Bearer token and still reach protected resources.

Consider an ASP.NET Core API that uses JWT Bearer authentication but accidentally excludes an endpoint from requiring a token:

// Insecure controller allowing anonymous access
[ApiController]
[Route("api/[controller]")]
public class ProfileController : ControllerBase
{
    [HttpGet("details")]
    [AllowAnonymous] // Bypass: token not required
    public IActionResult GetDetails()
    {
        return Ok(new { Message = "Public, but should require token" });
    }
}

Alternatively, authentication may be enforced globally but token validation can be bypassed via misconfigured schemes or policy requirements. For instance, specifying multiple authentication schemes without explicitly requiring the Bearer scheme can allow a request without any valid credentials to pass through:

// Startup-like configuration with a gap
services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = "BearerOrNone";
    options.DefaultChallengeScheme = "BearerOrNone";
}).AddJwtBearer("Bearer", jwtOptions =>
{
    // jwtOptions properly configured for Bearer
});
// If a fallback scheme allows anonymous access, a missing token may be accepted.

Authorization issues compound the problem. Even when authentication succeeds, improper role or scope checks can allow a token with limited privileges to access admin functionality. This maps to common attack patterns such as Insecure Direct Object References (IDOR) and broken access control (one of the OWASP API Top 10), where access control enforcement relies on the presence and correctness of the Bearer token rather than explicit per-endpoint authorization decisions.

During a scan, middleBrick tests unauthenticated attack surfaces and authenticated contexts where a Bearer token is either omitted or manipulated. It checks whether endpoints that should require token-based authentication inadvertently permit access without valid credentials, and whether authorization checks properly constrain actions per token claims. Findings include missing [Authorize] attributes, overly permissive CORS configurations, and gaps in policy-based authorization that enable an attacker to leverage a low-privilege token or no token at all to reach sensitive endpoints.

Remediation centers on ensuring every protected endpoint requires Bearer authentication and that token validation is correctly configured. Use the built-in JWT Bearer middleware with strict options and explicitly require authentication on controllers or actions.

First, configure authentication to require the Bearer scheme and validate tokens properly:

// Program.cs or Startup.cs
builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = "Bearer"
    options.DefaultChallengeScheme = "Bearer"
}).AddJwtBearer("Bearer", jwtOptions =>
{
    jwtOptions.Authority = "https://your-identity-provider";
    jwtOptions.Audience = "api1";
    jwtOptions.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        ValidIssuer = "https://your-identity-provider",
        ValidAudience = "api1"
    };
});

Second, enforce authentication on controllers and prefer policy-based authorization for fine-grained control:

[ApiController]
[Route("api/[controller]")]
[Authorize(AuthenticationSchemes = "Bearer")] // Require Bearer token
public class ProfileController : ControllerBase
{
    [HttpGet("details")]
    [Authorize(Policy = "ScopeProfileRead")] // Use policies for scopes/roles
    public IActionResult GetDetails()
    {
        return Ok(new { Message = "Profile details" });
    }

    [HttpPut("update")]
    [Authorize(Policy = "ScopeProfileWrite")]
    public IActionResult UpdateProfile([FromBody] ProfileUpdate model)
    {
        // update logic
        return NoContent();
    }
}

Third, avoid [AllowAnonymous] on endpoints that must require a token. If you need mixed access, explicitly allow anonymous on truly public endpoints and require Bearer on sensitive ones: