Cors Wildcard in Aspnet with Dynamodb

A CORS wildcard in an ASP.NET application that interacts with Amazon DynamoDB can unintentionally expose both data and control flow to any origin. When AllowAnyOrigin is enabled, the server responds to preflight and actual requests from any domain, which can combine poorly with DynamoDB-driven behavior if the response includes sensitive data or auth-related headers.

Consider an ASP.NET Core API that queries DynamoDB based on path or query parameters and returns item-level data. If the CORS policy uses AllowAnyOrigin and also includes credentials or exposes headers such as x-amzn-RequestId, a malicious site can make authenticated requests on behalf of users, leveraging cookies or tokens stored in the browser. This becomes critical when DynamoDB responses contain PII or when the API exposes write endpoints that can be invoked cross-origin.

In a black-box scan, middleBrick would flag this as a potential BFLA/IDOR and Data Exposure finding when a wildcard origin is paired with DynamoDB-derived data. For example, an endpoint like /items/{id} that returns a DynamoDB item could allow an attacker to enumerate identifiers via cross-origin requests if CORS does not restrict origins. The scanner also checks for reflected sensitive data in responses, which may include DynamoDB metadata or partial keys if error handling is misconfigured.

Real-world patterns that amplify risk include returning the full DynamoDB item (including internal attributes like SK or PK) and allowing credentials with a wildcard. OWASP API Top 10:2023 A05:2023 Security Misconfiguration and A01:2023 Broken Access Control are relevant here. A concrete risk scenario: a frontend hosted on https://evil.com uses JavaScript to call https://api.example.com/items/123, and the response includes data that should be restricted by tenant or scope because the CORS policy did not validate the origin.

middleBrick checks such configurations by correlating CORS rules with the presence of sensitive data in responses and by testing cross-origin behavior without credentials or with injected origins. The tool does not fix the policy but provides prioritized findings with remediation guidance, helping teams align with compliance frameworks such as OWASP API Top 10 and GDPR.

Remediation focuses on tightening CORS policy and ensuring DynamoDB responses do not leak sensitive information or enable cross-origin abuse. Use an allowlist of origins, avoid exposing internal headers, and apply scope-based access controls in your ASP.NET code and data layer.

1. Configure a restrictive CORS policy in ASP.NET

Replace AllowAnyOrigin with specific origins and avoid combining it with AllowCredentials. Prefer named policies and explicit methods.

// Program.cs (ASP.NET Core 6+)
builder.Services.AddCors(options =>
{
    options.AddPolicy("ApiCorsPolicy", policy =>
    {
        policy.WithOrigins("https://app.yourdomain.com", "https://admin.yourdomain.com")
              .AllowAnyMethod()
              .AllowAnyHeader()
              .AllowCredentials(); // only if required
    });
});

app.UseCors("ApiCorsPolicy");

2. Scope DynamoDB access by tenant or user

Ensure that every DynamoDB request includes a tenant or user context derived from the authenticated identity, preventing horizontal IDOR across accounts.

// Example using AWS SDK for .NET
public async Task<Dictionary

// Minimal DTO projection
public class ItemDto
{
    public string Id { get; set; }
    public string Name { get; set; }
    // Do not include RequestId, TableName, or internal attributes
}

// In your service or controller
var item = await GetItemAsync(id, tenantId);
var dto = new ItemDto
{
    Id = item["SK"].S,
    Name = item.TryGetValue("Name", out var nameAttr) ? nameAttr.S : null
};
return Ok(dto);

app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        context.Response.StatusCode = 500;
        await context.Response.WriteAsJsonAsync(new { error = "Request failed" });
    });
});

if (!Guid.TryParse(id, out _))
{
    Results.BadRequest(new { error = "Invalid item identifier" });
    return;
}