Api Key Exposure in Grape with Oracle Db

Grape is a REST-like API micro-framework for Ruby, often used to build endpoints that interact with backend systems such as an Oracle Database. When API keys are handled carelessly inside a Grape API that uses an Oracle Db backend, the attack surface includes both the HTTP interface and the database connection string. A common pattern is to store the key in an environment variable and interpolate it into a connection string, but mistakes in parameter handling, logging, or error reporting can expose the key through the API response or logs.

Consider a Grape endpoint that authenticates requests by passing an API key to a downstream service via an Oracle Db-stored credential. If the developer uses string interpolation to build the query or connection URI, an attacker might manipulate input to cause verbose error messages or unexpected query behavior. For example, a malformed request that triggers an Oracle error can return stack traces or connection strings containing the API key if exception handling is too verbose. Additionally, if Grape resources log incoming parameters without filtering, the API key may appear in application logs, creating a data exposure finding under the Data Exposure check.

Another scenario involves dynamic SQL built by concatenating user-controlled parameters with stored credentials retrieved from Oracle Db. Without strict input validation and parameterized queries, an attacker may leverage injection techniques to alter the query path and cause the application to return data it should not. This can result in findings for both Input Validation and Data Exposure. Because middleBrick tests unauthenticated endpoints and inspects error messages and returned data, it can detect when an API key leaks through error responses or logs, aligning with the Data Exposure and Input Validation checks.

LLM/AI Security relevance arises if the Grape API exposes an endpoint that interacts with an LLM service using an API key stored in Oracle Db. middleBrick’s LLM/AI Security checks look for system prompt leakage and output scanning. If an improperly handled Oracle Db credential leads to a misconfigured LLM endpoint or exposes keys in responses, middleBrick flags it as a potential system prompt or key exposure. The scanner does not assume architecture; it observes runtime behavior such as error messages, returned data, and response anomalies that may indicate leakage of sensitive material.

To illustrate, a Grape resource that retrieves a secret from a table and uses it to call an LLM might look like this in a vulnerable form. Note that this is a risky pattern and not a recommendation; it is shown to highlight how keys can be mishandled.

require 'oci8'
require 'grape'

class MyApi < Grape::API
  format :json

  resource :predict do
    get do
      key = nil
      # Dangerous: selecting a credential into a variable via dynamic SQL
      connection = OCI8.new('app_user', ENV['APP_PASSWORD'], '//localhost/XEPDB1')
      result = connection.exec_query('SELECT api_key FROM keys WHERE id = :1', [params[:key_id]])
      key = result.first['api_key'] if result && result.first

      # Risk: key may be logged or passed to an LLM endpoint without protection
      headers['Authorization'] = "Bearer #{key}"
      response = HTTP.headers(auth: "Bearer #{key}").get('https://llm.example.com/completions')
      { prediction: response.parse }
    rescue => e
      # Risk: exposing Oracle error details that may contain connection info
      error!({ error: e.message, backtrace: e.backtrace }, 500)
    end
  end
end

In this example, if the key_id parameter is not properly validated, an attacker might cause the query to return unexpected rows or trigger an error that exposes the key. The backtrace in the error response may reveal file paths or connection strings, and if logging is enabled, the key could be persisted in logs. middleBrick would flag the high severity Data Exposure and Input Validation findings and recommend parameterized queries, strict input validation, and redaction of sensitive data from errors and logs.

Remediation focuses on strict input validation, parameterized queries, safe error handling, and avoiding key exposure in logs and responses. Use bind variables for all user input, validate key_id against an allowlist, and ensure exceptions do not surface sensitive details.

Below is a secure version of the previous Grape resource. It demonstrates parameterized queries, input validation, and safe error reporting that prevent key leakage through Oracle Db interactions.

require 'oci8'
require 'grape'

class SecureApi < Grape::API
  format :json

  helpers do
    def safe_key_for(key_id)
      # Validate key_id is an integer to prevent injection and type confusion
      return nil unless key_id.to_s.match?(/^\d+$/)

      connection = OCI8.new('app_user', ENV['APP_PASSWORD'], '//localhost/XEPDB1')
      # Use bind variable for key_id; Oracle treats it as data, not executable code
      result = connection.exec_query('SELECT api_key FROM keys WHERE id = :id', [key_id])
      result.first&.fetch('api_key')
    rescue OCIError => e
      # Log the error internally without exposing details to the client
      # Use a structured logger that redacts sensitive values
      Rails.logger.error("Oracle query failed: #{e.message}") if defined?(Rails)
      nil
    ensure
      connection.logoff if connection
    end
  end

  resource :predict do
    get do
      key_id = params[:key_id]
      key = safe_key_for(key_id)

      unless key
        # Return a generic error to avoid leaking whether the key exists
        error!({ error: 'Invalid request' }, 400)
      end

      # Ensure key is not logged anywhere
      headers['Authorization'] = "Bearer #{key}"
      # Use a client that does not log sensitive headers automatically
      response = HTTP.headers(auth: "Bearer #{key}").get('https://llm.example.com/completions')
      { prediction: response.parse }
    rescue => e
      # Generic error to avoid information leakage
      error!({ error: 'Service unavailable' }, 500)
    end
  end
end

Key remediation points:

• Validate key_id with a strict pattern (e.g., digits only) before using it in a query.
• Use bind variables (`:id`) with OCI8 to ensure user input cannot alter SQL structure.
• Do not include stack traces or Oracle error details in responses; log them securely if needed for debugging.
• Ensure the connection is closed in an ensure block to prevent resource leaks.
• Avoid logging the key; if logging is necessary, ensure it is redacted or disabled for sensitive fields.

These steps reduce the likelihood of Api Key Exposure findings by ensuring that keys are not leaked through errors, logs, or improper query handling. middleBrick will still check the endpoint for residual risks such as Data Exposure and Input Validation, confirming that sensitive material is not returned or logged.