Fix Improper Error Handling in Rails

Information leakage via verbose error messages is a low-hanging fruit for any serious attacker. In Rails, dumping stack traces, database schema hints, or environment variables via internal server errors provides a roadmap for exploitation. If your production app is shouting 'ActiveRecord::RecordNotFound' or 'NoMethodError' at the client, you're leaking your internal architecture. Stop handing out the blueprint.

The Vulnerable Pattern

def show
  @user = User.find(params[:id])
rescue => e
  # LEAK: Sends the raw exception and full stack trace to the client
  render json: { error: e.message, trace: e.backtrace }, status: 500
end

The Secure Implementation

The vulnerable code directly exposes the ruby exception and backtrace, revealing file paths, gem versions, and logic flow to potential attackers. The secure implementation uses 'rescue_from' at the controller level to centralize error handling. It separates internal logging (which contains the full context for debugging) from the public API response (which returns an opaque, generic message). The inclusion of a 'request_id' allows developers to correlate user reports with internal logs without leaking system internals.

# app/controllers/application_controller.rb
class ApplicationController < ActionController::API
  rescue_from StandardError, with: :handle_internal_error
  rescue_from ActiveRecord::RecordNotFound, with: :handle_not_found
private
def handle_not_found
render json: { error: “Resource not found” }, status: :not_found
end
def handle_internal_error(e)
# Log the real error for dev eyes only
Rails.logger.error(”#{e.class}: #{e.message}\n#{e.backtrace.join(“\n”)}”)
# Return a generic message and a correlation ID for support
render json: {
  error: "An internal error occurred",
  request_id: request.uuid
}, status: :internal_server_error
end
end