Ssrf Server Side in Grape with Bearer Tokens

Server-side request forgery (SSRF) in a Grape API becomes more dangerous when requests rely on Bearer Tokens for authorization. In this combination, an attacker can coerce the server into making outbound HTTP requests to internal or restricted endpoints, and those requests may carry sensitive tokens that the service uses to call downstream APIs. Because Grape routes often forward requests to other services, a maliciously crafted URL in user input can lead the backend to include Bearer Tokens in headers it sends to unintended hosts. These tokens may have permissions that exceed what the client should possess, allowing lateral movement or data exposure within your infrastructure.

Grape APIs commonly accept URL parameters for webhook targets, status checks, or resource fetching. If the code does not validate or restrict the destination host, an attacker can supply an internal address such as http://169.254.169.254/latest/meta-data/iam/security-credentials/ or a service running on localhost that expects Bearer Tokens. When the server-side request executes, the Authorization header containing the Bearer Token is sent to the attacker-controlled target, potentially leaking credentials or enabling SSRF to pivot into internal networks. Even when tokens are scoped to specific endpoints, the risk remains because the server trusts user-supplied URLs and forwards authentication material without sufficient validation.

Middleware and instrumentation in Grape can inadvertently propagate tokens if they copy headers from the incoming request to outbound calls. Without explicit allowlists for destination hosts and strict header sanitization, patterns like Faraday or HTTP clients invoked from within resource classes may include the Authorization header automatically. This behavior turns a typical SSRF into a token-exposure path, where the compromised server acts as a proxy with the identity of the service account that holds the Bearer Token. Real-world examples include SSRF vectors tied to metadata services, cloud provider instance metadata endpoints, or internal monitoring APIs that accept Bearer Tokens and return sensitive operational data.

To mitigate SSRR in Grape when Bearer Tokens are used, start by avoiding the forwarding of Authorization headers to user-supplied URLs. Instead of blindly copying headers, explicitly define which headers are safe to propagate and remove any Authorization or Proxy-Authorization entries before making outbound calls. Use a strict allowlist of destination hosts and, when possible, move token usage to server-side secrets or service accounts that are not exposed to client-controlled endpoints.

Example: Unsafe forwarding in Grape

require 'grape'
require 'faraday'

class MyAPI < Grape::API
  format :json

  resource :fetch do
    params do
      requires :url, type: String, desc: 'Target URL'
    end
    get do
      # Vulnerable: forwards Authorization header to user-provided URL
      conn = Faraday.new(url: params[:url]) do |f|
        f.request :authorization, :Bearer, env['HTTP_AUTHORIZATION'].to_s.sub('Bearer ', '')
        f.adapter Faraday.default_adapter
      end
      conn.get
    end
  end
end

Example: Safe remediation with host allowlist and token isolation

require 'grape'
require 'faraday'

class MyAPI < Grape::API
  format :json

  ALLOWED_HOSTS = ['api.example.com', 'status.example.com'].freeze
  TOKEN_STORE = { 'service' => ENV['SERVICE_TOKEN'] }.freeze

  helpers do
    def safe_authorization_header
      # Use a server-side token, never forward client-supplied Authorization
      "Bearer #{TOKEN_STORE['service']}"
    end

    def allowed_host?(input_url)
      uri = URI.parse(input_url)
      ALLOWED_HOSTS.include?(uri.host)
    rescue URI::InvalidURIError
      false
    end
  end

  resource :fetch do
    params do
      requires :url, type: String, desc: 'Target URL'
    end
    get do
      unless allowed_host?(params[:url])
        error!('Destination not allowed', 400)
      end

      conn = Faraday.new(url: params[:url]) do |f|
        f.request :authorization, :Bearer, TOKEN_STORE['service']
        f.response :logger
        f.adapter Faraday.default_adapter
      end
      conn.get
    end
  end
end

Additional hardening practices

• Disable automatic forwarding of incoming Authorization headers in your HTTP client library.
• Use outbound connection timeouts and disable redirects for endpoints that should not follow chains.
• Rotate Bearer Tokens regularly and restrict their scope to least privilege for the intended downstream services.
• Monitor logs for repeated requests to sensitive internal endpoints that may indicate SSRF probing.