Open Redirect in Aspnet with Bearer Tokens

An Open Redirect in an ASP.NET application becomes particularly risky when combined with Bearer Token usage, as it can facilitate phishing and token theft. In ASP.NET, an open redirect typically occurs when a URL parameter is used to redirect a user without proper validation. For example, consider a common pattern where a returnUrl query string is passed to a redirect method:

// Example vulnerable pattern in an ASP.NET MVC controller
public ActionResult Login(string returnUrl)
{
    if (User.Identity.IsAuthenticated)
    {
        return Redirect(returnUrl); // No validation
    }
    // ... login logic
An attacker could craft a URL like https://api.example.com/login?returnUrl=https://evil.com. If the application redirects without validating that the returnUrl belongs to the trusted domain, the user is sent to a malicious site.
When Bearer Tokens are involved—such as when a client includes an Authorization header like Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...—the impact escalates. If a user is tricked into visiting the attacker-controlled URL while authenticated (with the token stored in a cookie or session), the application might unintentionally include the token in the redirect or expose the token in the browser’s referrer header. Some single-page app flows or OAuth client-side grant patterns use URL fragments or query parameters to pass tokens; if those are reflected into a redirect location, the token can be leaked to the third-party domain.
In the context of middleBrick’s checks, this is categorized under BOLA/IDOR and Input Validation because the redirect target is user-supplied and not strictly constrained. The scanner also flags missing validation on outbound redirects and checks whether authentication/authorization checks are applied before redirecting. The risk is compounded when the application relies on bearer tokens for authorization but does not ensure that redirects occur only to whitelisted origins, effectively bypassing the same-origin policy for token-bearing sessions.
To illustrate a safer approach, the remediation emphasizes strict allowlisting of hosts and schemes, and avoiding reflecting untrusted input into Location headers. This aligns with OWASP API Top 10 2023:2010 – Broken Redirect, and can be mapped to compliance frameworks such as PCI-DSS and SOC2 for controlling external navigation in authenticated contexts.

Secure remediation in ASP.NET involves validating redirect targets and ensuring Bearer Token handling does not inadvertently expose credentials. Below are concrete code examples demonstrating safe practices.

1. Validate redirect URLs against an allowlist

Always validate the returnUrl against a strict allowlist of hostnames and schemes. Do not rely on regex alone; use Uri to parse and compare hosts.

using System;\nusing System.Web;\n\npublic static bool IsRedirectAllowed(string url, string[] allowedHosts)\n{
    if (Uri.TryCreate(url, UriKind.Absolute, out var uri))
    {
        // Allow only HTTPS to prevent token leakage over insecure channels
        if (uri.Scheme != Uri.UriSchemeHttps)
            return false;
        foreach (var host in allowedHosts)
        {
            if (uri.Host.Equals(host, StringComparison.OrdinalIgnoreCase))
                return true;
        }
    }
    return false;
}\n\n// Usage in controller
private static readonly string[] TrustedHosts = { "api.example.com", "app.example.com" };
\npublic ActionResult Login(string returnUrl)
{
    if (!IsRedirectAllowed(returnUrl, TrustedHosts))
    {
        returnUrl = Url.Action("Index", "Home"); // Fallback to safe default
    }
    if (User.Identity.IsAuthenticated)
    {
        return Redirect(returnUrl);
    }
    // ... login logic
}

This prevents open redirects by ensuring the final destination is within your controlled domains and uses HTTPS, reducing the chance of token leakage via referrer headers.

2. Avoid including bearer tokens in redirect URLs

Never place bearer tokens as query parameters or URL fragments. If your flow requires passing tokens, keep them in the Authorization header. For SPAs, use short-lived tokens and store them securely (e.g., httpOnly cookies with SameSite=Strict) rather than in localStorage, and avoid redirecting with tokens in the URL.

3. Use Anti-Forgery tokens and referrer policy

Combine redirect validation with defense-in-depth measures. Enforce a strict Referrer-Policy to suppress the Referer header when navigating away, and use anti-forgery tokens for state-changing operations to mitigate CSRF if the redirect is used in a form context.

app.UseReferrerPolicy(opts => opts.NoReferrerWhenDowngrade());\n// In ConfigureServices for policy-based authorization, ensure redirect validation is part of the workflow.

By applying these patterns—validated allowlists, HTTPS enforcement, and careful token handling—you reduce the attack surface for open redirect vulnerabilities that could lead to Bearer Token compromise. These measures align with the checks provided by middleBrick’s scans, which flag unvalidated redirects and highlight remediation steps to help maintain a secure API surface.