Pii Leakage in Aspnet with Basic Auth

Basic Authentication over unencrypted channels is a common cause of PII leakage in ASP.NET APIs. With Basic Auth, credentials are encoded in Base64 and sent in the Authorization header. Because Base64 is not encryption, an attacker who intercepts the traffic can easily decode the credentials. If the API does not enforce HTTPS, credentials and any user identifying information (such as usernames or emails used as identifiers) can be captured in cleartext.

ASP.NET APIs that accept Basic Auth may inadvertently expose PII when responses include user details in error messages or when endpoints return sensitive profile data without adequate authorization checks. For example, a user profile endpoint like /api/users/{id} might rely on Basic Auth for initial entry but then return PII such as email addresses, phone numbers, or government identifiers in the JSON payload. Without additional property-level authorization, an attacker who gains valid credentials can harvest large amounts of PII.

During a black-box scan, middleBrick tests unauthenticated and authenticated paths to detect whether PII is present in responses and whether credentials are transmitted in a reversible or weakly protected form. When an OpenAPI spec defines security schemes using basic security and endpoints return user data, middleBrick correlates the spec definitions with runtime responses to identify missing data exposure controls. Findings may include missing transport encryption, overly broad authentication scopes, and endpoints that disclose PII such as emails or IDs in JSON responses.

SSRF and input validation issues can compound the risk. If an endpoint accepts a user-supplied URL or identifier and uses Basic Auth credentials to fetch remote resources, an attacker may induce the server to make unintended requests to internal services, leaking PII from internal APIs that trust the caller. Input validation flaws may allow injection attacks that manipulate responses to include sensitive fields. middleBrick’s Data Exposure and SSRF checks look for these patterns by analyzing spec definitions and runtime outputs, including cases where LLM-style tool usage or agent patterns expose additional sensitive fields.

Compliance mappings such as OWASP API Top 10 (2023) A3:2023 – Injection and A7:2021 – Data Exposure are relevant when PII is returned without proper filtering or access controls. middleBrick reports these findings with severity ratings and remediation guidance, emphasizing the need to protect credentials in transit, enforce strict authorization on PII fields, and validate all inputs that affect server-side behavior.

Remediation focuses on enforcing HTTPS, avoiding the use of sensitive information in usernames, and ensuring responses do not leak PII. Always use HTTPS to protect credentials in transit and prevent decoding by intermediaries. Do not embed PII such as email addresses in usernames used for Basic Auth; instead, use a non-identifying token or ID and map it server-side to user details.

Implement strict authorization on endpoints that return user data. Use policy-based checks to ensure a user can only access their own profile and that sensitive fields are omitted unless explicitly required. Below is an example of enabling Basic Auth in Program.cs with HTTPS enforcement and scoped authorization.

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAuthentication("Basic")
    .AddScheme("Basic", null);
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("OwnProfile", policy =>
        policy.RequireAssertion(context =>
            context.User.HasClaim(c => c.Type == "sub") &&
            context.User.FindFirst("sub")?.Value == context.Resource?.GetType().GetProperty("UserId")?.GetValue(context.Resource)?.ToString()));
});
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
var app = builder.Build();
app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();
app.MapGet("/api/users/me", (UserProfile profile) =>
{
    // Return only necessary fields, exclude PII like email if not needed
    return Results.Ok(new { profile.UserId, profile.Username, profile.Role });
}).RequireAuthorization("OwnProfile");
app.Run();

Create a custom BasicAuthenticationHandler that validates credentials without storing or logging sensitive values. Ensure the handler does not write credentials to logs and uses constant-time comparison for password checks.

// BasicAuthenticationHandler.cs
public class BasicAuthenticationHandler : AuthenticationHandler<AuthenticationSchemeOptions>
{
    public BasicAuthenticationHandler(
        IOptionsMonitor<AuthenticationSchemeOptions> options,
        ILoggerFactory logger,
        UrlEncoder encoder,
        ISystemClock clock) : base(options, logger, encoder, clock) { }

    protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        if (!Request.Headers.ContainsKey("Authorization"))
            return AuthenticateResult.NoResult();

        var authHeader = Request.Headers["Authorization"].ToString();
        if (!authHeader.StartsWith("Basic ", StringComparison.OrdinalIgnoreCase))
            return AuthenticateResult.NoResult();

        var token = authHeader.Substring("Basic ".Length).Trim();
        var credentialBytes = Convert.FromBase64String(token);
        var credentials = Encoding.UTF8.GetString(credentialBytes).Split(':');
        var username = credentials[0];
        var password = credentials.Length > 1 ? credentials[1] : string.Empty;

        // Validate credentials securely, avoid logging username/password
        if (IsValidUser(username, password))
        {
            var claims = new[] { new Claim(ClaimTypes.NameIdentifier, username) };
            var identity = new ClaimsIdentity(claims, Scheme.Name);
            var principal = new ClaimsPrincipal(identity);
            var ticket = new AuthenticationTicket(principal, Scheme.Name);
            return AuthenticateResult.Success(ticket);
        }
        return AuthenticateResult.Fail("Invalid credentials.");
    }

    private bool IsValidUser(string username, string password)
    {
        // Use secure password hashing and constant-time comparison
        // Example: retrieve user record and verify hash
        return true; // placeholder
    }
}

For endpoints that return user data, apply property-level filtering to exclude PII unless the caller is authorized. Use DTOs that omit sensitive fields and validate input identifiers to prevent IDOR. middleBrick’s Property Authorization and BOLA/IDOR checks can help detect missing constraints.

Finally, enable continuous monitoring if you use the Pro plan to catch regressions. The GitHub Action can fail builds when a scan detects PII exposure or weak authentication, and the MCP Server allows you to run scans directly from your IDE while developing. These integrations support rapid feedback without requiring a separate pentest cycle.