Logging Monitoring Failures in Aspnet with Mongodb

In an ASP.NET application using MongoDB, insufficient logging and monitoring create a blind spot that can hide abuse, slow performance degradation, and complicate incident response. When requests reach an endpoint that performs MongoDB operations, the lack of structured logs and metrics means failed logins, malformed queries, or excessive document scans may never be surfaced. Without correlation of HTTP status codes, user identifiers, and MongoDB driver diagnostics, attacks such as NoSQL injection or credential stuffing can proceed undetected.

This gap is especially risky because MongoDB drivers in .NET can throw exceptions for invalid pipelines, index issues, or network timeouts. If these are not captured and logged with sufficient context (operation ID, user ID, filter document shape, and stack trace), operators cannot reconstruct an attacker’s path. For example, an unmonitored FindAsync with an empty filter { } could silently return large datasets, indicating BFLA or data exposure, but without logs the issue remains invisible.

Additionally, the ASP.NET pipeline may short-circuit before MongoDB is called (e.g., due to model validation errors), which can fragment the audit trail. If health checks or liveness probes do not include a lightweight MongoDB call, a failing database may be missed until users report errors. Together, these logging and monitoring failures shift risk toward data exposure and availability issues, as suspicious patterns go unnoticed and remediation is delayed.

Remediation focuses on enriching observability while keeping MongoDB interactions safe and observable. Implement structured logging with correlation IDs, capture command outcomes, and expose key metrics for query shapes and error rates. Below are concrete code examples for an ASP.NET Minimal API using the official MongoDB C# driver.

1. Structured logging with correlation IDs

Use a logging framework (e.g., Microsoft.Extensions.Logging) to emit consistent events. Include operation identifiers and sanitized representations of filters to avoid logging sensitive data.

using MongoDB.Driver;
using Microsoft.Extensions.Logging;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSingleton(_ =>
    new MongoClient(builder.Configuration.GetConnectionString("MongoDb") ?? throw new InvalidOperationException("Missing MongoDB connection string"))
);
builder.Services.AddLogging();
var app = builder.Build();

app.MapGet("/users/{id}", async (string id, IMongoClient client, ILogger<Program> logger, HttpContext http) =>
{
    using var scope = logger.BeginScope(new Dictionary<string, object> { ["CorrelationId"] = http.TraceIdentifier });
    var database = client.GetDatabase("shop");
    var coll = database.GetCollection<BsonDocument>("users");
    logger.LogInformation("Querying user by id. Filter: {{UserId}}, Operation: {{Operation}}", id, "FindById");
    try
    {
        var filter = Builders<BsonDocument>.Filter.Eq("_id", id);
        var result = await coll.Find(filter).FirstOrDefaultAsync();
        if (result == null)
        {
            logger.LogWarning("User not found. Filter: {{Filter}}", filter.ToString());
            return Results.NotFound();
        }
        logger.LogInformation("User retrieved. Filter: {{Filter}}", filter.ToString());
        return Results.Ok(result);
    }
    catch (MongoException ex)
    {
        logger.LogError(ex, "MongoDB error. Operation: FindById, Filter: {{Filter}}", filter?.ToString());
        return Results.StatusCode(500);
    }
});

2. Monitoring query shape and performance

Track operation types and filter patterns to detect anomalous scans. Emit metrics for document counts, execution time, and error types; integrate with your observability platform as needed.

app.MapGet("/products", async (IMongoClient client, ILogger<Program> logger) =>
{
    var database = client.GetDatabase("shop");
    var coll = database.GetCollection<BsonDocument>("products");
    var filter = new BsonDocument(); // intentionally empty to demonstrate scan detection
    var stopwatch = System.Diagnostics.Stopwatch.StartNew();
    try
    {
        var cursor = await coll.FindAsync(filter);
        var count = await cursor.CountAsync();
        stopwatch.Stop();
        logger.LogInformation("Products scan. Documents: {{Count}}, DurationMs: {{Duration}}, Filter: {{Filter}}", count, stopwatch.ElapsedMilliseconds, filter.ToString());
        if (count > 1000)
        {
            logger.LogWarning("Large scan detected. Count: {{Count}}", count);
        }
        return Results.Ok(new { Total = count });
    }
    catch (MongoException ex)
    {
        stopwatch.Stop();
        logger.LogError(ex, "Products scan failed. DurationMs: {{Duration}}, Filter: {{Filter}}", stopwatch.ElapsedMilliseconds, filter.ToString());
        return Results.StatusCode(500);
    }
});

3. Health checks and command monitoring

Include a lightweight MongoDB command in health probes to detect database issues early and log them with context.

app.MapGet("/health", async (IMongoClient client, ILogger<Program> logger) =>
{
    var database = client.GetDatabase("admin");
    try
    {
        var result = await database.RunCommandAsync(new BsonDocument("ping", 1));
        logger.LogInformation("MongoDB ping succeeded. Reply: {{Reply}}", result.ToJson());
        return Results.Ok();
    }
    catch (MongoException ex)
    {
        logger.LogError(ex, "MongoDB ping failed");
        return Results.StatusCode(503);
    }
});

4. Centralizing logs and alerts

Ensure logs include severity, correlation identifiers, and sanitized filter shapes. Configure alerts on patterns such as repeated empty-filter queries, high document return volumes, or frequent MongoException errors to detect potential BFLA, IDOR, or data exposure scenarios.