Open Redirect in Grape with Cockroachdb

An Open Redirect in a Grape API that uses Cockroachdb typically arises when a URL or host value from user-controlled input is used to construct a redirect response without strict validation. If a parameter such as redirect_to, next, or a host field from the database is reflected into the Location header, an attacker can craft links that route users to arbitrary external sites.

Consider a Grape endpoint that reads a redirect target from a Cockroachdb-stored configuration or a user profile field and then performs a redirect:

get '/external_redirect' do
  target = params[:target]
  # Unsafe: target may come from query string and is used directly
  redirect target, allow_other_host: true
end

If the target is not validated against a whitelist or normalized to a safe domain, an attacker can supply https://evil.com and abuse the trusted origin to phish users. In a Cockroachdb-backed service, you might also load the redirect destination from a row:

get '/user_redirect' do
  org = params[:org]
  # Fetch redirect_url from Cockroachdb for the given org
  row = DB[%Q{SELECT redirect_url FROM orgs WHERE name = $1}].first(org)
  redirect row[:redirect_url], allow_other_host: true
end

Here, if redirect_url is user-controlled or not strictly validated, an attacker who can influence the Cockroachdb record (via compromised credentials, SQL injection, or supply-chain issues) can cause persistent open redirects. Even if the database is trusted, storing arbitrary URLs without validation and then using them in redirect with allow_other_host: true exposes the API to external redirection abuse.

An additional risk occurs when the API normalizes or rewrites URLs in application code and then redirects to the computed value without verifying the host. For example, concatenating a user-supplied path to a base URL read from Cockroachdb can yield open redirects if the base URL or path is not strictly constrained.

Because middleBrick scans the unauthenticated attack surface and includes checks for authentication flaws and BOLA/IDOR, it can flag endpoints where redirects depend on external input or database values without strict allowlisting. middleBrick also maps findings to frameworks such as OWASP API Top 10 to highlight injection and host-parameter risks.

Remediation focuses on never trusting input for redirect targets and enforcing allowlists for hosts or paths. Avoid using raw user input or unchecked database fields in redirect. Instead, resolve the destination server-side and only allow known-safe paths or hosts.

1) Use a hardcoded or config-based allowlist of destinations

ALLOWED_HOSTS = ['app.example.com', 'docs.example.com'].freeze

get '/safe_redirect' do
  org = params[:org]
  row = DB[%Q{SELECT redirect_key FROM orgs WHERE name = $1}].first(org)
  key = row[:redirect_key]
  url = if ALLOWED_HOSTS.include?(key)
          key
        else
          '/fallback'
        end
  redirect url
end

2) Map keys to full URLs server-side instead of storing full URLs in Cockroachdb

# Store only keys in Cockroachdb; map to full URLs in code
URLS_MAP = {
  'pricing' => 'https://pricing.example.com',
  'terms'   => 'https://legal.example.com/terms'
}.freeze

get '/mapped_redirect' do
  key = params[:key]
  row = DB[%Q{SELECT url_key FROM orgs WHERE name = $1}].first(org)
  url = URLS_MAP.fetch(row[:url_key], nil)
  if url
    redirect url
  else
    error!('Invalid redirect target', 400)
  end
end

3) Validate protocol and host when a URL must be stored

require 'uri'

def safe_redirect_url(input)
  uri = URI.parse(input)
  return nil unless %w[http https].include?(uri.scheme)
  return nil unless uri.host&.end_with?('example.com')
  # Ensure no unexpected ports or paths that lead to open redirects
  uri.path = '' unless uri.path.start_with?('/allowed')
  uri.to_s
rescue URI::InvalidURIError
  nil
end

get '/validated_redirect' do
  candidate = params[:candidate]
  safe = safe_redirect_url(candidate)
  if safe
    redirect safe
  else
    error!('Invalid redirect URL', 400)
  end
end

Using middleBrick’s GitHub Action you can add API security checks to your CI/CD pipeline and fail builds if risk scores exceed your threshold, helping prevent insecure redirects from reaching production. For continuous protection, the Pro plan provides continuous monitoring so changes in redirect configurations or database values are scanned on a configurable schedule with alerts.