Open Redirect in Aspnet with Mutual Tls

An open redirect in an ASP.NET application occurs when user-controlled input is used to redirect the client to an arbitrary URL without proper validation. Even when mutual TLS (mTLS) is enforced, the server-side redirect logic can remain vulnerable because mTLS secures the channel between client and server, but does not constrain what happens after the server decides to redirect.

With mutual TLS, the client presents a certificate and the server validates it before establishing the secure session. This ensures that only authorized clients can reach the endpoint. However, if the endpoint accepts a target URL (e.g., a returnUrl query parameter) and redirects to it without strict allowlisting, an authenticated mTLS client can be tricked into following a malicious redirect. The secure channel does not protect against application-level logic flaws.

For example, an OAuth callback endpoint that uses mTLS to authenticate clients might read a returnUrl from the request and issue return Redirect(returnUrl). If returnUrl is not validated against a whitelist of trusted origins, an attacker can supply a malicious external URL. The mTLS certificate grants access to the endpoint, but the redirect itself is unchecked. This becomes a phishing vector where the client’s trusted TLS session is abused to lend credibility to the malicious destination.

In an API security scan, this would typically be flagged under BFLA/Privilege Escalation or Property Authorization checks, because the redirect behavior may expose functionality or data to contexts not intended by the designer. The scanner does not assume mTLS negates input validation; it tests whether the endpoint enforces strict rules regardless of transport-layer identity.

To remediate open redirect in ASP.NET while using mutual TLS, validate redirect targets explicitly and avoid using raw user input for navigation. Below are concrete code examples that demonstrate a secure pattern.

First, ensure your application is configured to require client certificates. In Program.cs, enforce HTTPS and mTLS:

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            // Optionally configure client certificate validation
            httpsOptions.ClientCertificateValidation = (cert, chain, errors) =>
            {
                // Perform custom validation if needed, or rely on default chain validation
                return errors == System.Security.Cryptography.X509Certificates.X509ChainStatusFlags.NoError;
            };
        });
    });
});
// Additional services and middleware
builder.Services.AddAuthorization();
var app = builder.Build();
app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();
app.MapGet("/callback", (HttpRequest request) =>
{
    // Secure handling of returnUrl
    var returnUrl = request.Query["returnUrl"].ToString();
    var allowedHosts = new[] { "app.example.com", "trusted.example.org" };
    var uri = new Uri(returnUrl, UriKind.RelativeOrAbsolute);
    if (!uri.IsAbsoluteUri || !allowedHosts.Contains(uri.Host))
    {
        return Results.BadRequest("Invalid return URL.");
    }
    return Results.Redirect(returnUrl);
}).RequireAuthorization();
app.Run();

This example demonstrates that even with mTLS in place, you must validate the redirect target. The validation checks that the URL is absolute and its host is within an allowlist. This prevents open redirects while preserving legitimate post-login flows.

Alternatively, if your application only supports a fixed set of return URLs, use a whitelist of paths or route names instead of raw URLs:

app.MapGet("/oauth/callback", (HttpRequest request, IUrlHelper urlHelper) =>
{
    var returnPath = request.Query["returnUrl"].ToString() ?? "/home";
    // Only allow known, safe paths relative to the app
    if (!returnPath.StartsWith("/", StringComparison.Ordinal) || returnPath.Contains("//"))
    {
        return Results.Redirect(urlHelper.Content("/home"));
    }
    return Results.Redirect(returnPath);
}).RequireAuthorization();

Combine these practices with continuous scanning. Using the middleBrick CLI (middlebrick scan <url>) or the GitHub Action to add API security checks to your CI/CD pipeline can help detect open redirect patterns and other misconfigurations early, even when mTLS is used.