Open Redirect in Grape with Basic Auth

An open redirect in a Grape API combined with HTTP Basic Authentication creates a nuanced risk where an authenticated session or token can be leveraged to redirect a user to a malicious site. Grape is a Ruby web framework for building REST-like APIs, and it often uses before filters to enforce Basic Auth. If the application includes a redirect response (e.g., using redirect) and derives the target URL from user-controlled input without strict validation, an authenticated attacker can abuse this to steer credentials or session tokens to an attacker-controlled endpoint.

Consider an endpoint that accepts a next_url parameter to redirect after login or token issuance. If the API validates credentials via Basic Auth but then redirects to next_url without ensuring it is a same-origin or strictly allowed URI, the authentication context can be misused. An attacker might craft a link like https://api.example.com/authenticate?next_url=https://evil.com. When a victim with valid Basic Auth credentials follows the link, the server redirects to the attacker’s domain, potentially exposing the Authorization header in logs or browser behavior, and undermining trust in the API’s domain.

In a black-box scan, middleBrick tests for open redirects by probing endpoints that accept redirect parameters while supplying Basic Auth headers. The tool checks whether the response is a 3xx and whether the Location header reflects a user-supplied value without a strict allowlist. Because Basic Auth is often handled in before filters, the scan verifies whether authentication is applied before or after the redirect decision, and whether credentials are at risk of being sent to an external host. This combination is particularly dangerous in APIs used by single-page applications or mobile clients that store tokens in headers and rely on server-side redirects for post-login flows.

Real-world patterns mirror findings from related checks such as Input Validation and BOLA/IDOR, where untrusted input leads to unsafe behavior. The scan references the OWASP API Top 10 category for Security Misconfiguration and highlights the importance of validating and restricting redirect targets. For example, an allowlist of domains or a rule that only permits relative paths can mitigate the issue. middleBrick’s report will flag this as a high-severity finding and provide remediation guidance tied to API security best practices.

To remediate open redirect vulnerabilities in Grape when using Basic Auth, ensure that redirect targets are not directly derived from user input, or if they are, they are validated against a strict allowlist. Below are concrete code examples showing a vulnerable pattern and a secure implementation.

Vulnerable Grape endpoint with Basic Auth and open redirect:

# config.ru or Grape API definition
class VulnerableAPI < Grape::API
  before do
    authenticate!
  end

  helpers do
    def authenticate!
      authenticate_or_request_with_http_basic do |username, password|
        # Simplified check; use secure password verification in production
        username == 'admin' && password == 'secret'
      end
    end
  end

  get '/redirect' do
    # Unsafe: directly uses user-supplied next_url
    next_url = params[:next_url]
    redirect next_url, 302
  end
end

This pattern allows an authenticated user to supply any URL, causing the server to redirect the victim’s browser to a malicious site. The Authorization header is sent before the redirect, potentially leaking credentials to the attacker if the victim follows the link.

Secure Grape endpoint with Basic Auth and safe redirect:

class SecureAPI < Grape::API
  before do
    authenticate!
  end

  helpers do
    def authenticate!
      authenticate_or_request_with_http_basic do |username, password|
        # Use secure credential verification
        username == 'admin' && password == 'secret'
      end
    end

    def safe_redirect_url
      # Allow only relative paths or strictly controlled domains
      allowed_hosts = ['api.example.com', 'app.example.com']
      provided = params[:next_url]
      if provided && allowed_hosts.include?(URI.parse(provided).host)
        provided
      else
        # Default to a safe internal endpoint
        '/dashboard'
      end
    rescue URI::InvalidURIError
      '/dashboard'
    end
  end

  get '/redirect' do
    redirect safe_redirect_url, 302
  end
end

In the secure version, the server parses the user input, validates the host against an allowlist, and falls back to a safe internal path if validation fails. This prevents open redirects while preserving legitimate use cases such as redirecting to known internal views. middleBrick’s scan will verify that such controls are in place and will not flag the endpoint if the redirect logic is constrained.

Additionally, consider using relative redirects when possible, and avoid including sensitive tokens in URLs. Combine this with Content Security Policy headers and strict input validation to reduce the risk of abuse. The GitHub Action can be configured to fail builds if open redirect patterns are detected in your codebase, while the CLI can be run locally with middlebrick scan <url> to validate fixes before deployment.