HIGH llm data leakageaspnetbearer tokens

Llm Data Leakage in Aspnet with Bearer Tokens

Llm Data Leakage in Aspnet with Bearer Tokens — how this specific combination creates or exposes the vulnerability

LLM data leakage in an ASP.NET API commonly occurs when application logic inadvertently exposes sensitive information—including bearer tokens—in prompts sent to LLM endpoints. Because bearer tokens are often stored in request headers, logs, or debug payloads, they can become inputs to LLM calls if the developer does not explicitly sanitize them.

In an ASP.NET pipeline, incoming HTTP requests typically carry authorization headers such as Authorization: Bearer {token}. If the application constructs a prompt by concatenating headers, query strings, or body content before forwarding that data to an LLM, the token may be included in the system or user messages. This exposes the token to the LLM provider, risking unauthorized access to the protected resource represented by that token and potential exfiltration through the LLM output or logs.

Moreover, middleware or custom action filters that enrich telemetry or diagnostics with request details may inadvertently include the authorization header. When those diagnostics are sent to an LLM for analysis—whether for anomaly detection, natural language explanations, or automated triage—the token can be leaked. Even if the LLM provider claims content moderation, proactive detection is necessary because leakage can occur in intermediate representations, cached traces, or error messages returned to the client.

ASP.NET developers might also use LLM capabilities to generate code or explanations based on request context. If the context includes the bearer token—for example, to correlate API behavior with identity—without redaction, the token becomes part of the prompt. This is particularly risky when using public or shared LLM endpoints where outputs may be retained for training or viewed by other tenants.

The risk is compounded when applications also forward raw request data or logs to LLMs for summarization. A bearer token embedded in logs, error details, or telemetry can be extracted from LLM responses through prompt injection techniques that trick the model into revealing its input. Therefore, any integration that sends request-derived data to LLMs must explicitly exclude or mask bearer tokens and other credentials before transmission.

Bearer Tokens-Specific Remediation in Aspnet — concrete code fixes

Remediation focuses on ensuring bearer tokens never reach LLM endpoints and are stripped from any data used in prompts. Below are concrete steps and code examples for ASP.NET Core applications.

  • Redact headers before constructing prompts:
var authHeader = Request.Headers["Authorization"].ToString();
string sanitizedPrompt;
if (authHeader.StartsWith("Bearer ", StringComparison.OrdinalIgnoreCase)) {
    // Do not include the token in the prompt
    sanitizedPrompt = $"User query: {userInput}";
} else {
    sanitizedPrompt = $"User query: {userInput}";
}
// Use sanitizedPrompt when calling the LLM
  • Use a message formatter that excludes sensitive headers:
var messages = new List<ChatMessage> {
    new SystemChatMessage("You are a helpful assistant."),
    new UserChatMessage($"Query: {userInput}")
    // Do not append headers or tokens
};
var options = new ChatCompletionsOptions(messages);
// Do not add custom data that includes Authorization headers
  • Configure logging to exclude bearer tokens:
// In Program.cs or logging configuration
builder.Logging.AddFilter("Microsoft.AspNetCore.Http", level: LogLevel.Warning);
// Use a custom formatter or enricher to scrub tokens
  • Validate and sanitize any data forwarded to LLM utilities:
void SendToLLM(string userInput) {
    // Ensure no token is present
    if (userInput.Contains("Bearer ", StringComparison.OrdinalIgnoreCase)) {
        throw new ArgumentException("Input contains potential token leakage");
    }
    // Proceed with safe input
}
  • Apply middleware to remove sensitive headers early:
app.Use(async (context, next) => {
    var auth = context.Request.Headers["Authorization"].ToString();
    if (!string.IsNullOrEmpty(auth) && auth.StartsWith("Bearer ")) {
        // Optionally store token securely for server-side use without exposing to LLM
        context.Items["BearerToken"] = auth;
        // Remove from headers if they will be forwarded to LLM
        context.Request.Headers["Authorization"] = "[REDACTED]";
    }
    await next();
});

These practices help ensure that bearer tokens remain within secure server contexts and are not exposed to LLM endpoints, reducing the risk of credential leakage and unauthorized access.

Related CWEs: llmSecurity

CWE IDNameSeverity
CWE-754Improper Check for Unusual or Exceptional Conditions MEDIUM

Frequently Asked Questions

How can I verify that bearer tokens are not being sent to the LLM endpoint in my ASP.NET application?
Instrument your HTTP client or middleware to log outgoing requests and confirm that the Authorization header is either absent or redacted. Use a proxy or network trace to inspect payloads sent to the LLM service and ensure no bearer token values are present.
Is it safe to include bearer tokens in LLM prompts if the LLM provider is trusted?
No. Even with trusted providers, including bearer tokens in prompts increases exposure surface and may appear in outputs, logs, or retained training data. Tokens should be excluded from all LLM inputs and handled only in secure server-side contexts.