Phishing Api Keys in Aspnet with Basic Auth

In ASP.NET applications, using HTTP Basic Authentication to transmit API keys creates a phishing risk that stems from how credentials are handled across the full stack. Basic Auth sends credentials in an Authorization header encoded as Base64, which is easily reversible. If an attacker can trick a user or an intermediary into submitting a request to a malicious endpoint, the credentials can be harvested. This is especially dangerous in ASP.NET when the same secret is used both as an API key and as a Basic Auth credential, because a single phishing vector can expose two authentication factors.

Consider an ASP.NET Core API that accepts a static API key via a header (e.g., x-api-key) while also using Basic Auth for an administrative endpoint. A phishing campaign might deliver a link to a look‑alike admin page that calls the Basic Auth endpoint. If the page includes JavaScript that reads the response headers or triggers a request to the API, the Base64‑encoded credentials can be exfiltrated. Because the API key is often embedded in client‑side code or configuration, a compromised Basic Auth credential can lead to an attacker reconstructing or guessing the API key, enabling unauthorized access to backend services.

Another vector involves log aggregation and error reporting. If ASP.NET logs the Authorization header in plaintext during debugging or error handling, and those logs are centralized, a phishing attack that compromises a log viewer or SIEM credential can expose both the Basic Auth credential and the associated API key. This is compounded when OpenAPI specs with $ref resolution are publicly accessible, as they may inadvertently document authentication schemes that reveal how credentials are expected to be formatted and transmitted.

middleBrick detects these risks by scanning the unauthenticated attack surface and cross‑referencing spec definitions with runtime behavior. For example, it checks whether authentication headers are transmitted over non‑TLS channels, whether credentials appear in logs or error messages, and whether the API key is redundantly exposed through multiple mechanisms. The scanner’s Authentication and Data Exposure checks highlight endpoints where Basic Auth is used in combination with key‑based identification, and the LLM/AI Security module looks for prompt‑injection patterns that could be used to coax credentials out of error messages or help text. Findings include severity ratings and remediation guidance mapped to frameworks such as OWASP API Top 10 and PCI‑DSS.

middleBrick can be integrated into your workflow via the CLI (middlebrick scan <url>), the GitHub Action to gate CI/CD pipelines, or the MCP Server for IDE‑level scanning. These integrations do not alter runtime behavior but ensure that risky authentication combinations are identified before deployment, reducing the window for phishing exploitation.

To mitigate phishing risks when using Basic Auth in ASP.NET, move credentials out of the request header and avoid sending API keys in the same channel. Use token‑based or certificate‑based authentication for privileged operations, and if Basic Auth must be retained, enforce strict transport security and avoid logging credentials.

Below are concrete code examples for secure ASP.NET Core authentication. The first example shows how to disable Basic Auth for sensitive endpoints and use scoped API keys validated via middleware, preventing the same secret from serving dual purposes.

// Program.cs — configure authentication without Basic Auth for API keys
var builder = WebApplication.CreateBuilder(args);

// Do not add Basic Auth if you rely on API‑key style identification
// If you must support Basic Auth, restrict it to a limited admin path
builder.Services.AddAuthentication("ApiKeyScheme")
    .AddScheme("ApiKeyScheme", null);

var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();

app.MapGet("/public/health", () => "Healthy");
app.MapGroup("/api")
    .AddApiKey()
    .MapGet("/data", (HttpContext context) => $"Data for {context.User.Identity?.Name}");

app.Run();

public class ApiKeyHandler : AuthenticationHandler
{
    private const string ApiKeyHeader = "x-api-key";
    private static readonly HashSet ValidKeys = new() { "2cR1A2B3-4567-890D-EF12-34567890ABcD" };

    protected override Task HandleAuthenticateAsync()
    {
        if (!Request.Headers.TryGetValue(ApiKeyHeader, out var apiKey))
        {
            return Task.FromResult(AuthenticateResult.Fail("Missing API Key"));
        }
        if (!ValidKeys.Contains(apiKey))
        {
            return Task.FromResult(AuthenticateResult.Fail("Invalid API Key"));
        }
        var claims = new[] { new Claim(ClaimTypes.Name, "api-key-user") };
        var identity = new ClaimsIdentity(claims, Scheme.Name);
        var principal = new ClaimsPrincipal(identity);
        var ticket = new AuthenticationTicket(principal, Scheme.Name);
        return Task.FromResult(AuthenticateResult.Success(ticket));
    }
}

The second example shows how to restrict Basic Auth to a narrow administrative route with mandatory HTTPS, ensuring credentials are not phished via mixed‑content or insecure redirects.

// Program.cs — limit Basic Auth to admin routes and enforce HTTPS
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAuthentication("Basic")
    .AddScheme("Basic", null);

var app = builder.Build();
app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();

// Public endpoints without Basic Auth
app.MapGet("/status", () => Results.Ok(new { status = "ok" }));

// Admin endpoint with Basic Auth
app.MapGroup("/admin")
    .RequireAuthorization()
    .WithApplicationOfAuthentication("Basic")
    .MapGet("/settings", () => Results.Json(new { config = "secure" }));

app.Run();

public class BasicAuthHandler : AuthenticationHandler
{
    protected override Task HandleAuthenticateAsync()
    {
        if (!Request.Headers.ContainsKey("Authorization"))
            return Task.FromResult(AuthenticateResult.Fail("Missing Authorization Header"));

        var authHeader = Request.Headers["Authorization"].ToString();
        if (!authHeader.StartsWith("Basic ", StringComparison.OrdinalIgnoreCase))
            return Task.FromResult(AuthenticateResult.Fail("Invalid Scheme"));

        var token = authHeader.Substring("Basic ".Length).Trim();
        var credentialString = Encoding.UTF8.GetString(Convert.FromBase64String(token));
        var credentials = credentialString.Split(':', 2);
        var username = credentials[0];
        var password = credentials[1];

        // Validate credentials securely; avoid using the same value as an API key
        if (username == "admin" && password == "S3cur3P@ss!") // Replace with secure validation
        {
            var claims = new[] { new Claim(ClaimTypes.Name, username) };
            var identity = new ClaimsIdentity(claims, "Basic");
            var principal = new ClaimsPrincipal(identity);
            var ticket = new AuthenticationTicket(principal, "Basic");
            return Task.FromResult(AuthenticateResult.Success(ticket));
        }
        return Task.FromResult(AuthenticateResult.Fail("Invalid Credentials"));
    }
}

These examples demonstrate specific remediation: separate authentication schemes, HTTPS enforcement, and avoiding credential reuse. They reduce the attack surface for phishing by ensuring API keys are not transmitted in the same channel as Basic Auth credentials and that sensitive endpoints are explicitly protected. middleBrick’s scans validate these configurations by checking for authentication inconsistencies and header exposures, providing prioritized findings with remediation steps.