Open Redirect in Laravel with Hmac Signatures

An open redirect occurs when an application redirects a user to an arbitrary URL without proper validation. In Laravel, developers sometimes use signed URLs with Hmac Signatures to ensure the integrity of redirect targets. While Hmac Signatures help verify that a parameter has not been tampered with, they do not inherently validate that the target is a safe, trusted location. If the application uses the signature to authenticate a redirect URL that is stored or controlled indirectly (for example, a return_to query parameter), an attacker may be able to supply a malicious external URL that still passes signature verification when the signing key and algorithm are misapplied or when the signature is computed over an insufficient scope.

Consider a typical pattern where a client is sent to a signed redirect URL after login:

GET /login/redirect?url=https%3A%2F%2Fexample.com%2Fdashboard&sig=abc123

If the server validates only that the signature is correct (using Laravel’s hash_hmac or custom signature verification) without ensuring the URL host matches an allowed set, an attacker can provide a signed URL pointing to a malicious host (e.g., https://evil.com/phish). Because the signature is derived from the attacker-controlled URL, the server may incorrectly treat the redirect as safe, leading to a reflected or stored open redirect. This becomes particularly relevant when the signature uses a weak scope (such as only the path) while the host is uncontrolled, or when the signature is computed over a concatenation of parameters without strict normalization, enabling parameter confusion or injection.

Real-world scenarios often involve OAuth clients or SSO flows where a redirect URL is negotiated via query parameters. If an application signs the full redirect target to prevent tampering but does not validate the destination against a whitelist, the Hmac Signature can give a false sense of security. The signature confirms integrity but not trustworthiness. Attack patterns such as CVE-2021-23394 (Laravel’s signed URL handling) highlight how improper validation of signed redirect targets can lead to open redirects despite the presence of cryptographic guarantees.

Moreover, if the signature algorithm or key management is weak (e.g., using predictable keys or failing to scope the signature to a specific action and timestamp), an attacker might replay or manipulate the signed value to produce a valid redirect to an arbitrary domain. Even when Laravel’s URL::signedRoute or custom middleware is used, the responsibility to enforce host allowlisting remains with the developer. Without explicit validation of the redirect host, the combination of Hmac Signatures and dynamic redirect targets creates a pathway for open redirect vulnerabilities.

To mitigate open redirect risks when using Hmac Signatures in Laravel, you must combine signature verification with strict host validation and scope control. Never rely on the signature alone to determine whether a redirect target is safe.

1) Validate the redirect host against an explicit allowlist before performing the redirect. Do not trust any user-supplied host, even if the signature is valid.

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;

function safeRedirect(Request $request)
{
    $validator = Validator::make($request->all(), [
        'url' => 'required|url',
        'sig' => 'required|string',
    ]);

    if ($validator->fails()) {
        abort(400, 'Invalid parameters');
    }

    $url = $request->input('url');
    $providedSig = $request->input('sig');
    $parsed = parse_url($url);
    $host = $parsed['host'] ?? '';

    $allowedHosts = ['app.example.com', 'dashboard.example.com'];
    if (!in_array($host, $allowedHosts, true)) {
        abort(400, 'Redirect to disallowed host');
    }

    $expected = hash_hmac('sha256', $url, config('app.redirect_signing_key'));
    if (!hash_equals($expected, $providedSig)) {
        abort(403, 'Invalid signature');
    }

    return redirect()->to($url);
}

2) When using Laravel’s built-in signed routes, scope the signature to the intended action and include a timestamp to prevent replay. Then verify both the signature and the host before redirecting:

use Illuminate\Support\Facades\Route;
use Illuminate\Http\Request;

Route::get('/redirect/{path}', function (Request $request, string $path) {
    // Ensure the route is signed and the signature is valid
    if (! $request->hasValidSignature()) {
        abort(403, 'Invalid signature');
    }

    // Reconstruct the full URL from trusted inputs and validate host
    $url = request()->input('url');
    $parsed = parse_url($url);
    $host = $parsed['host'] ?? '';

    $allowedHosts = ['app.example.com', 'dashboard.example.com'];
    if (!in_array($host, $allowedHosts, true)) {
        abort(400, 'Redirect target not allowed');
    }

    return redirect()->to($url);
})->name('redirect.target')->middleware('signed');

3) Avoid including the full redirect URL in the signed payload if you can derive the target from trusted parameters. Instead, sign an identifier and map it server-side to an allowed URL. This minimizes the attack surface and ensures the signature scope is tightly controlled:

$allowedMap = [
    'dashboard' => 'https://app.example.com/dashboard',
    'profile'   => 'https://app.example.com/profile',
];

$key = config('app.redirect_signing_key');
$action = $request->input('action'); // e.g., 'dashboard'
$providedSig = $request->input('sig');

$expected = hash_hmac('sha256', $action, $key);
if (!hash_equals($expected, $providedSig)) {
    abort(403, 'Invalid signature');
}

$url = $allowedMap[$action] ?? null;
if (!$url) {
    abort(400, 'Invalid action');
}

return redirect()->to($url);

Always use hash_equals for signature comparison to prevent timing attacks, and enforce a short lifetime for signed payloads where applicable. These measures ensure that Hmac Signatures contribute to integrity without undermining host trust validation.