Broken Access Control in Aspnet with Bearer Tokens

Broken Access Control occurs when API endpoints do not properly enforce authorization checks, allowing one user to access or modify another user’s resources. In ASP.NET APIs that rely on Bearer Tokens, this often arises from missing or misapplied authorization policies, over-privileged roles, or incorrect route/parameter validation. Even when tokens are validated for authenticity, the API may fail to confirm that the authenticated subject is allowed to operate on the specific resource identified in the request.

Consider an endpoint like GET /api/users/{id}. If the route parameter id is taken from the URL but never compared to the user identity extracted from the Bearer Token, an attacker can simply change id to access other users’ data. This is a classic BOLA/IDOR pattern. In ASP.NET, this can happen when controllers rely on implicit trust in route data and do not explicitly verify that the resource belongs to the caller’s scope.

Another common scenario involves role-based or policy-based authorization that is inconsistently applied. For example, an action may be protected by [Authorize] but lack specific policy requirements such as [Authorize(Policy = "IsOwner")]. If policies are not rigorously enforced across all endpoints, users may escalate privileges by leveraging permissions assigned to less privileged roles. Insecure default configurations in Program.cs or missing global authorization filters can further widen the attack surface.

Input validation also plays a role. An attacker may supply malformed identifiers or exploit weak model binding to bypass expected constraints. If the API does not validate that the token’s subject matches the requested resource, or if it fails to sanitize inputs that influence data access logic, the unauthenticated attack surface grows. This is especially risky when OpenAPI specs are not aligned with runtime authorization logic, causing discrepancies between declared scopes and actual enforcement.

middleBrick scans for these authorization gaps as part of its BOLA/IDOR and Property Authorization checks, comparing declared OpenAPI/Swagger definitions (including securitySchemes using Bearer tokens) with runtime behavior. The scanner runs 12 checks in parallel to highlight missing or inconsistent authorization rules, providing prioritized findings with severity levels and remediation guidance rather than attempting to fix the issues automatically.

To secure ASP.NET APIs using Bearer Tokens, consistently apply policy-based authorization, validate resource ownership, and ensure every endpoint enforces checks based on the token’s claims. Below are concrete, working examples that demonstrate secure patterns.

1. Configure Bearer Authentication and Policies in Program.cs

Set up authentication and fine-grained authorization policies so that access is granted only when explicit conditions are met.

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.AspNetCore.Authorization;
using Microsoft.IdentityModel.Tokens;
using System.Text;

var builder = WebApplication.CreateBuilder(args);

// Add authentication with Bearer Tokens
builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        ValidIssuer = "https://your-issuer.example.com",
        ValidAudience = "https://your-api.example.com",
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("your-very-secure-key-here-keep-it-secret"))
    };
});

// Define policies
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("IsOwner", policy =>
        policy.RequireClaim("role", "owner"));
    options.AddPolicy("CanViewUser", policy =>
        policy.Requirements.Add(new UserIdRequirement()));
});

// Register any custom handlers if needed
builder.Services.AddSingleton();

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

2. Enforce Policy-Based Authorization on Endpoints

Apply policies at the controller or action level and always resolve resource ownership within the handler or service layer.

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    private readonly AppDbContext _context;

    public UsersController(AppDbContext context)
    {
        _context = context;
    }

    // Example: Ensure the caller can only view their own profile
    [HttpGet("{id}")]
    [Authorize(Policy = "CanViewUser")]
    public async Task<IActionResult> GetUser(Guid id)
    {
        var userIdClaim = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
        if (string.IsNullOrEmpty(userIdClaim) || !Guid.TryParse(userIdClaim, out var userId))
        {
            return Unauthorized();
        }

        if (id != userId)
        {
            return Forbid();
        }

        var user = await _context.Users.FindAsync(id);
        if (user == null)
        {
            return NotFound();
        }

        return Ok(new { user.Id, user.Username, user.Email });
    }

    // Example: Admin-only action
    [HttpDelete("{id}")]
    [Authorize(Policy = "IsOwner")]
    public async Task<IActionResult> DeleteUser(Guid id)
    {
        var user = await _context.Users.FindAsync(id);
        if (user == null)
        {
            return NotFound();
        }

        _context.Users.Remove(user);
        await _context.SaveChangesAsync();
        return NoContent();
    }
}

3. Use a Custom Authorization Handler for Resource-Based Checks

Implement IAuthorizationHandler to encapsulate rules that compare route parameters or payload identifiers with token claims.

public class UserIdRequirement : IAuthorizationRequirement { }

public class UserIdHandler : AuthorizationHandler<UserIdRequirement, Guid>
{
    protected override async Task HandleRequirementAsync(
        AuthorizationHandlerContext context,
        UserIdRequirement requirement,
        Guid resourceId)
    {
        var userIdClaim = context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
        if (string.IsNullOrEmpty(userIdClaim) || !Guid.TryParse(userIdClaim, out var userId))
        {
            return;
        }

        if (resourceId == userId)
        {
            context.Succeed(requirement);
        }

        // Optionally fetch ownership from a service/database for complex scenarios
        await Task.CompletedTask;
    }
}

By combining Bearer Token authentication with policy-based authorization, explicit resource checks, and handler-based rules, you reduce the risk of Broken Access Control. middleBrick’s scans can validate that your OpenAPI spec reflects these policies and that runtime behavior aligns with declared security requirements.