Api Key Exposure in Aspnet with Mongodb

When an ASP.NET application connects to MongoDB, mishandled configuration or logging can unintentionally expose API keys used for authentication. MongoDB connection strings and API keys are often stored in configuration files, environment variables, or injected at runtime. If the ASP.NET app logs connection details, exception messages, or serializes configuration objects to responses, keys may leak through application output or error pages.

Insecure deserialization or improper model binding in ASP.NET can also reflect configuration values back to the client. For example, returning a full MongoDB client settings object in an API response may reveal embedded credentials. Similarly, verbose MongoDB driver logging or misconfigured diagnostic switches can emit connection strings containing keys in clear text to logs or debug consoles.

Another vector arises when ASP.NET endpoints construct MongoDB queries using concatenated or interpolated strings derived from user input. Without strict input validation, an attacker may manipulate the query shape to trigger error messages that disclose configuration snippets, including API keys used for authentication. This aligns with typical injection and information exposure patterns seen in the OWASP API Top 10, particularly Excessive Data Exposure and Improper Error Handling.

middleBrick detects these risks by performing unauthenticated black-box scans that test endpoints for information leakage, improper error messages, and unsafe exposure of configuration-derived data. The scanner runs checks across categories such as Data Exposure, Input Validation, and Unsafe Consumption, mapping findings to frameworks like OWASP API Top 10 and providing prioritized remediation guidance rather than attempting to fix the service.

Using the middleBrick CLI, you can quickly evaluate an ASP.NET + MongoDB endpoint from the terminal:

middlebrick scan https://api.example.com

For continuous assurance, the Pro plan supports scheduled scans and GitHub Action integration to fail builds if risk scores degrade, while the MCP server enables scanning directly from AI coding assistants in your IDE.

Remediation centers on preventing API keys from appearing in logs, error messages, or responses, and on safely constructing MongoDB interactions in ASP.NET.

1. Secure Configuration and Connection Handling

Store connection strings and API keys outside of source code. Use ASP.NET Core configuration providers and secret management, and avoid serializing configuration objects to the client.

// appsettings.json (do not commit secrets here)
{
  "MongoDbSettings": {
    "ConnectionString": "mongodb+srv://user:[email protected]/db"
  }
}

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSingleton(sp => {
    var cs = sp.GetRequiredService<IConfiguration>()["MongoDbSettings:ConnectionString"];
    // Use MongoClientSettings for fine-grained control without exposing keys in strings
    var settings = MongoClientSettings.FromConnectionString(cs);
    // Ensure credentials are not logged by the driver
    settings.ClusterConfigurator = cb => cb
        .ConfigureConnectionPoolSettings(cps => cps.MaxConnectionIdleTime = TimeSpan.FromSeconds(30));
    return new MongoClient(settings);
});
var app = builder.Build();

2. Avoid Logging Sensitive Information

Configure MongoDB driver logging to suppress connection strings and keys. In ASP.NET Core, filter sensitive data from logs and ensure exceptions do not leak configuration details.

// Program.cs — suppress verbose driver logging
builder.Logging.ClearProviders();
builder.Logging.AddConsole((options) => {
    options.Filter = (category, level) => {
        // Exclude MongoDB connection string logs
        return !category.StartsWith("MongoDB.Driver") || level > LogLevel.Warning;
    };
});

3. Safe Query Construction and Input Validation

Use strongly-typed definitions and avoid interpolating user input into query filters. This prevents information disclosure via error messages and injection-based leakage.

// Example document model
public class Product {
    public ObjectId Id { get; set; }
    public string Name { get; set; }
    public string Category { get; set; }
}

// Safe query in a controller
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase {
    private readonly IMongoCollection<Product> _products;

    public ProductsController(IMongoClient client) {
        var database = client.GetDatabase("shop");
        _products = database.GetCollection<Product>("products");
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<Product>> GetById(string id) {
        if (!ObjectId.TryParse(id, out var objectId)) {
            return BadRequest("Invalid identifier");
        }
        var filter = Builders<Product>.Filter.Eq(p => p.Id, objectId);
        var item = await _products.Find(filter).FirstOrDefaultAsync();
        if (item == null) {
            return NotFound();
        }
        return Ok(item);
    }
}

4. Error Handling and Response Sanitization

Do not return raw MongoDB exceptions or configuration details. Use standardized error responses that avoid exposing internal state.

// Exception handling middleware
app.UseExceptionHandler(errorApp => {
    errorApp.Run(async context => {
        context.Response.StatusCode = 500;
        await context.Response.WriteAsJsonAsync(new {
            error = "An internal error occurred.",
            requestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier
        });
    });
});