Insufficient Logging in Aspnet

In ASP.NET applications, insufficient logging creates a critical blind spot where security events go unrecorded, hindering breach detection and forensic analysis. This deficiency typically manifests in several ASP.NET-specific patterns.

1. Development-Only Error Details in Production: The common UseDeveloperExceptionPage() middleware, when accidentally deployed, exposes stack traces and internal paths to attackers while failing to log these errors centrally. Attackers can probe for vulnerabilities like CVE-2020-0688 (View State MAC validation bypass) without triggering any audit trail.

2. Unlogged Authorization Failures: ASP.NET's [Authorize] attribute and policy-based authorization silently reject unauthorized requests with 401/403 status codes by default. Without explicit logging middleware, these authentication bombing attempts remain invisible. For example, a brute-force attack against an API endpoint using [Authorize(Roles="Admin")] generates no log entries.

3. Silent Middleware Failures: Custom middleware that catches exceptions without logging, such as:

public async Task InvokeAsync(HttpContext context, RequestDelegate next)
{
    try
    {
        await next(context);
    }
    catch (Exception)
    {
        // Swallowing exception without logging
        context.Response.StatusCode = 500;
    }
}

This pattern suppresses error details and creates zero telemetry. Similarly, health check endpoints (MapHealthChecks()) often lack audit logging for unauthorized access attempts.

4. Missing Audit Trails for Sensitive Operations: Operations like user role changes via UserManager.AddToRoleAsync() or data exports from controllers often execute without any ILogger calls. An attacker who compromises an account could exfiltrate data via an API endpoint like GET /api/export/customers with no trace in logs.

5. Unstructured or Non-Persistent Logs: Relying solely on Console.WriteLine() or Debug.WriteLine() in ASP.NET Core means logs are lost on app recycle. Production systems often misconfigure appsettings.json to use LogLevel.Information for Microsoft.AspNetCore but omit application-specific categories:

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "Microsoft.AspNetCore": "Warning"
      // No logging for "MyApp.Security"
    }
  }
}

This filters out security-relevant events from custom components.

middleBrick's black-box scanning detects insufficient logging in ASP.NET APIs through behavioral analysis and response inspection, without requiring credentials or agents.

Verbose Error Message Detection: The scanner sends malformed requests (e.g., invalid JSON, missing required parameters) to endpoints. If responses contain ASP.NET exception details like System.NullReferenceException or stack traces referencing Microsoft.AspNetCore.Mvc.Infrastructure, it indicates production error pages are enabled without proper logging abstraction. For example, a response body containing "An error occurred while processing your request." plus a stackTrace field signals UseDeveloperExceptionPage() is active.

Authorization Event Gaps: middleBrick probes endpoints with invalid/missing JWTs and monitors for absence of security headers like WWW-Authenticate or logging-specific headers (e.g., X-Request-ID when correlated with logs). A consistent 401 without WWW-Authenticate suggests authorization failures aren't being logged via ILogger in authentication handlers.

Health Check Misconfiguration: Scanning /health or /healthz endpoints reveals if they return 200 OK for unauthenticated requests. If the endpoint also lacks Cache-Control: no-store headers, it may expose internal state without audit logging.

Logging Configuration Analysis: When an OpenAPI/Swagger spec is provided, middleBrick cross-references endpoint security definitions (securitySchemes) with runtime behavior. If an endpoint requires ApiKey authentication but accepts requests without logging the missing key, it flags a logging gap. The scanner also checks for absence of standard logging middleware by analyzing response times—silent catches often show consistent 500ms delays without variation.

Example middleBrick CLI Scan:

middlebrick scan https://api.example.com --format json

The output includes a dedicated "Logging & Monitoring" category score (0–100) with findings like:

• High: Error responses disclose internal paths (CWE-209)
• Medium: Authorization failures not logged
• Low: Health check endpoint publicly accessible

Each finding maps to OWASP API Top 10:2023 API09:2023 – Improper Logging and includes remediation steps tailored to ASP.NET, such as configuring Serilog sinks or ILogger scopes.

Remediation requires leveraging ASP.NET Core's built-in logging abstractions and structured logging libraries. Never rely on ad-hoc logging.

1. Centralized Exception Logging with UseExceptionHandler: Replace UseDeveloperExceptionPage() in production with:

app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        var exceptionHandlerPathFeature = 
            context.Features.Get<IExceptionHandlerPathFeature>();
        var logger = context.RequestServices
            .GetRequiredService<ILogger<Program>>();
        
        logger.LogError(exceptionHandlerPathFeature.Error,
            "Unhandled exception for path {Path}",
            context.Request.Path);
        
        context.Response.StatusCode = 500;
        await context.Response.WriteAsync("An error occurred.");
    });
});

This logs full exception details (including stack trace) to configured sinks while returning generic messages to clients. Ensure appsettings.json sets "Logging": { "LogLevel": { "Default": "Information" } }.

2. Audit Logging Middleware for Authorization Events: Create middleware that logs all 401/403 responses:

public class AuditLoggingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<AuditLoggingMiddleware> _logger;
    
    public AuditLoggingMiddleware(RequestDelegate next, 
        ILogger<AuditLoggingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }
    
    public async Task InvokeAsync(HttpContext context)
    {
        await _next(context);
        
        if (context.Response.StatusCode == 401 || 
            context.Response.StatusCode == 403)
        {
            _logger.LogWarning(
                "Authorization failure: {StatusCode} for {Path} by {User}",
                context.Response.StatusCode,
                context.Request.Path,
                context.User?.Identity?.Name ?? "Anonymous");
        }
    }
}

// In Program.cs:
app.UseMiddleware<AuditLoggingMiddleware>();

3. Structured Logging for Sensitive Operations: Inject ILogger<T> into controllers/services and use scopes for audit trails:

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    private readonly ILogger<UsersController> _logger;
    private readonly UserManager<IdentityUser> _userManager;
    
    public UsersController(ILogger<UsersController> logger,
        UserManager<IdentityUser> userManager)
    {
        _logger = logger;
        _userManager = userManager;
    }
    
    [HttpPost("roles")]
    [Authorize(Roles = "Admin")]
    public async Task<IActionResult> AddToRole(string userId, string role)
    {
        using (_logger.BeginScope(new Dictionary<string, object>
        {
            ["UserId"] = userId,
            ["Role"] = role,
            ["Operation"] = "RoleAssignment",
            ["Initiator"] = User.Identity?.Name
        }))
        {
            var result = await _userManager.AddToRoleAsync(
                await _userManager.FindByIdAsync(userId), role);
            
            if (result.Succeeded)
            {
                _logger.LogInformation("Role {Role} assigned to user {UserId}",
                    role, userId);
                return Ok();
            }
            _logger.LogWarning("Failed to assign role {Role} to user {UserId}: {Errors}",
                role, userId, string.Join(",", result.Errors.Select(e => e.Description)));
            return BadRequest(result.Errors);
        }
    }
}

4. Configure Serilog for Persistent Storage: Use Serilog with Seq or file sinks in Program.cs:

Log.Logger = new LoggerConfiguration()
    .Enrich.FromLogContext()
    .WriteTo.Seq("http://localhost:5341") // Or .WriteTo.File("logs/log-.txt", rollingInterval: RollingInterval.Day)
    .WriteTo.Console()
    .CreateLogger();

builder.Host.UseSerilog();

5. Secure Health Checks: Restrict health endpoints and log access:

app.MapHealthChecks("/health", new HealthCheckOptions
{
    Predicate = _ => true,
    ResponseWriter = async (context, report) =>
    {
        var logger = context.RequestServices
            .GetRequiredService<ILogger<Program>>();
        logger.LogInformation("Health check accessed from {IP} with status {Status}",
            context.Connection.RemoteIpAddress, report.Status);
        await context.Response.WriteAsync(
            JsonSerializer.Serialize(report));
    }
}).RequireAuthorization(); // Or use IP restrictions

6. Log Retention and GDPR Compliance: Implement log rotation and PII redaction. Use Serilog.Filters.Expressions to exclude sensitive fields:

.WriteTo.Seq(...)
.Filter.ByExcluding(Matching.WithProperty("CreditCard"));

Never log raw request bodies containing PII. Instead, log hashed identifiers or metadata only.

Given ASP.NET's flexible middleware pipeline, logging gaps can re-emerge during refactoring. middleBrick's Pro tier offers continuous monitoring: APIs are rescanned weekly (or daily) with automated alerts if the "Logging & Monitoring" category score drops. Integrate the GitHub Action to fail PRs that introduce unlogged endpoints:

name: API Security Scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: middlebrick/github-action@v1
        with:
          api-url: ${{ env.API_URL }}
          fail-below-score: 80
          categories: logging-monitoring

This ensures every code change preserves auditability. The MCP Server allows scanning directly from your IDE—paste an endpoint URL from your ASP.NET solution into Claude/Cursor to get immediate feedback on logging coverage before commit.