Missing Tls in Aspnet with Bearer Tokens

Transport Layer Security (TLS) is the baseline mechanism that protects data in transit between clients and an ASP.NET API. When TLS is missing or misconfigured, all communications—including bearer tokens—are sent in cleartext. This specific combination is particularly dangerous because bearer tokens function as equivalent to passwords; if intercepted, an attacker can impersonate the token owner without needing to crack or reuse secrets.

In ASP.NET applications, missing TLS often occurs when developers run services locally on HTTP or when production endpoints are accidentally exposed without enforcing HTTPS. Because bearer tokens are typically transmitted via the Authorization header, any request that does not use TLS leaves the token visible to anyone on the network path. This exposure enables on-path attackers to capture tokens using techniques such as ARP spoofing, rogue Wi‑Fi access points, or compromised network appliances.

Another scenario involves mixed content and redirect issues. An ASP.NET application might listen on HTTPS but redirect HTTP requests to HTTPS without strict HSTS (HTTP Strict Transport Security). During the redirect, the bearer token can be exposed if it was initially sent over HTTP or if the client follows the redirect without strict policy enforcement. Additionally, if TLS termination is handled by a load balancer or reverse proxy and the backend communication between the proxy and ASP.NET app is unencrypted, tokens can be exposed internally within the infrastructure, violating the principle of end-to-end protection.

The risk is compounded when token handling practices are weak. For example, logging HTTP requests without redacting the Authorization header can inadvertently persist bearer tokens in plaintext logs. Without TLS, these logs become a secondary source of exposure. Furthermore, tools that perform unauthenticated scans—such as the 12 parallel security checks run by middleBrick—will flag missing TLS as a high-severity finding because it directly undermines token confidentiality and enables session hijacking.

Real-world attack patterns illustrate the impact. Consider an ASP.NET API that issues bearer tokens over HTTP during a login redirect. An attacker on the same network can capture the token and use it to call protected endpoints, bypassing authentication entirely. This maps to common weaknesses enumerated in frameworks such as OWASP API Security Top 10 and can also intersect with findings related to data exposure and insufficient transport protections that middleBrick reports across its checks.

Securing bearer tokens in ASP.NET requires enforcing TLS and hardening token handling in code and configuration. The following examples demonstrate how to configure an ASP.NET Core application to require HTTPS, set secure cookie and header policies, and validate token transmission.

Enforce HTTPS and HSTS

Ensure that the application redirects all HTTP traffic to HTTPS and that HSTS is enabled to prevent downgrade attacks. This protects bearer tokens during redirects and initial requests.

// Program.cs (ASP.NET Core 6+)
var builder = WebApplication.CreateBuilder(args);

// Enforce HTTPS redirection for all requests
builder.Services.Configure<HstsOptions>(opts =>
{
    opts.MaxAge = TimeSpan.FromDays(365);
    opts.IncludeSubDomains = true;
    opts.Preload = true;
});

var app = builder.Build();
app.UseHttpsRedirection();
app.UseHsts();

// Require HTTPS for all endpoints
app.Use(async (context, next) =>
{
    if (!context.Request.IsHttps)
    {
        context.Response.StatusCode = 403;
        await context.Response.WriteAsync("HTTPS required.");
        return;
    }
    await next.Invoke();
});

app.Run();

Secure Bearer Token Authentication

Configure authentication to require HTTPS and validate token issuance and usage. This ensures tokens are only accepted over encrypted channels.

// Program.cs (authentication setup)
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.RequireHttpsMetadata = true; // Reject tokens on non-HTTPS
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "https://your-secure-issuer.com",
            ValidateAudience = true,
            ValidAudience = "https://your-api-audience",
            ValidateLifetime = true,
            ClockSkew = TimeSpan.FromMinutes(5)
        };
    });

app.UseAuthentication();
app.UseAuthorization();

Protect Against Token Leakage in Logs and Errors

Ensure that logging frameworks do not capture Authorization headers. Configure filters to redact sensitive headers and avoid exposing tokens in error responses.

// Configure logging to filter headers (ASP.NET Core)
app.Use(async (context, next) =>
{
    // Remove Authorization header from logs
    var originalHeader = context.Request.Headers["Authorization"].ToString();
    if (!string.IsNullOrEmpty(originalHeader))
    {
        context.Request.Headers["Authorization"] = "[Filtered]";
    }
    await next();
    // Restore if needed downstream
});

Use Secure Transmission for Token Issuance

When issuing bearer tokens, ensure the response is sent over HTTPS and that tokens are not embedded in URLs or query strings, which can leak via referrer headers or logs.

// Example token endpoint
app.MapPost("/auth/login", (LoginModel login) =>
{
    // Validate credentials securely
    if (IsValidUser(login))
    {
        var token = GenerateJwtToken(login.Username);
        return Results.Ok(new { access_token = token });
    }
    return Results.Unauthorized();
});

Continuous Monitoring and Scanning

Use tools that support unauthenticated scans—offered by platforms like middleBrick—to detect missing TLS and related misconfigurations. The CLI can integrate scanning into scripts, while the GitHub Action can fail builds if the API security score drops below your defined threshold. The MCP Server enables scanning directly from AI coding assistants to catch issues early in development.