Open Redirect in Grape with Bearer Tokens

An open redirect in a Grape API occurs when an endpoint uses an untrusted value to form a redirect response, enabling an attacker to steer victims to arbitrary locations. This risk is compounded when Bearer Tokens are involved because the token may be exposed during or after the redirect.

In Grape, developers sometimes build a redirect helper that reads a query parameter such as next or redirect_to and passes it directly to redirect. If the parameter is not strictly validated or confined to a safe set of paths, an attacker can supply a full external URL. When a request includes an Authorization header with a Bearer Token, the browser may send that token to the external site if the redirect is followed in a user context. Even in server-side integrations, logging or error handling might inadvertently surface the token if the redirect causes an outbound request to a malicious endpoint.

Consider a typical pattern that is insecure:

# Insecure example: open redirect with Bearer Token exposure risk
class V1::AuthResource < Grape::API
  format :json
  before { header['WWW-Authenticate'] = 'Bearer realm="api"' }

An attacker can supply a crafted URL like https://api.example.com/auth/callback?next=https://evil.com. If the endpoint performs an unvalidated redirect, the victim’s browser follows the redirect and may include cookies or fragments that expose the token. Additionally, if the server internally traces the redirect chain (for example, to validate reachability), the token could be logged or passed to an external service, creating a data exposure path.

Another scenario involves token leakage via the Referer header. When a browser follows a redirect from a secure origin to an external site, it may include the Referer header with the full URL, including any token present in the original request. This can expose the Bearer Token to the destination site, even if the redirect itself is syntactically valid.

Grape APIs that issue access tokens or interact with OAuth flows must treat redirect targets as untrusted input. Without strict allowlisting of host or path patterns, the combination of open redirect and Bearer Token handling can lead to token theft or phishing campaigns that abuse the trusted API domain.

Remediation focuses on validating redirect targets and ensuring Bearer Tokens are never exposed to untrusted destinations. Use allowlisted hosts or relative paths, avoid including tokens in URLs, and ensure tokens are handled only over secure channels.

Secure implementation example with host allowlist:

# Secure example: restrict redirect_to to known hosts
class V1::AuthResource < Grape::API
  format :json

  ALLOWED_REDIRECT_HOSTS = ['app.example.com', 'static.example.com'].freeze

Validate the target and default to a safe path if validation fails:

helpers do
  def safe_redirect_target(default_path = '/')
    target = params['redirect_to'] || default_path
    # Allow only relative paths or same-host absolute paths
    if target.start_with?('http')
      uri = URI.parse(target)
      if ALLOWED_REDIRECT_HOSTS.include?(uri.host)
        target
      else
        default_path
      end
    else
      # Relative path is safe
      target
    end
  end
end

Use the helper in your endpoint to perform the redirect safely:

post '/auth/callback' do
  redirect_to = safe_redirect_target('/dashboard')
  redirect redirect_to, 303

Avoid including Bearer Tokens in the URL query or fragment. Instead, rely on server-side session storage or cryptographically signed tokens that can be validated without exposing raw secrets. If you must pass a token client-side, use short-lived tokens and ensure strict Referrer-Policy headers to limit leakage.

For APIs that integrate with OAuth providers, configure redirect URIs explicitly in the provider registration and validate the state parameter to prevent open redirect abuse. Never construct redirect URLs by concatenating user input directly.