Cross Site Request Forgery in Grape

Cross Site Request Forgery (CSRF) in Grape manifests when a mutation endpoint relies only on HTTP methods and parameters without verifying the request origin or intent. In Grape, this commonly appears in namespaced API classes where developers focus on resource representation and forget anti-CSRF controls for state-changing routes. For example, an endpoint that changes an account email or upgrades a subscription may accept PUT/PATCH/POST with JSON payloads but lack origin checks, CSRF tokens, or same-site cookie attributes.

Grape-specific code paths where CSRF risk is common include:

• Endpoints under a versioned API class (e.g., class V1::Users < Grape::API) that use params directly without authenticity checks.
• Nested resources such as resources :projects do; resources :invitations, only: [:create, :destroy] where the route relies on path parameters alone.
• Endpoints that set session cookies (e.g., via rack_session or custom Warden integration) and perform actions like password change or role escalation without a per-request token or referrer/origin validation.

A concrete Grape example of a vulnerable endpoint:

class V1::Accounts < Grape::API
  format :json
  before { authenticated? } # assumes session or token, but does not enforce CSRF protection for state-changing verbs

  desc 'Update email on the current account'
  params do
    requires :email, type: String, format?: URI::MailTo::EMAIL_REGEXP
  end
  put '/account/email' do
    current_user.update!(email: declared(params)[:email])
    { status: 'ok' }
  end
end

If this endpoint relies on a session cookie and does not validate Origin or X-CSRF-Token, an attacker can trick a logged-in user into submitting a forged request from another site. Similarly, destructive actions such as delete or put that change financial or security settings are high-risk without anti-CSRF measures. Attack patterns include embedding images or forms on attacker-controlled pages that submit authenticated requests to the Grape API, leveraging browser credential inclusion to perform unauthorized state changes.

Detecting CSRF in Grape involves scanning for endpoints that mutate state without verifying request authenticity. With middleBrick, you submit the base URL of your Grape service and the scanner runs black-box checks across the unauthenticated attack surface. One of the 12 parallel checks tests for missing CSRF protections on mutation endpoints, examining whether the API requires an origin/referrer check or a synchronizer token pattern for PUT, POST, PATCH, and DELETE routes.

To identify these issues manually while developing, focus on:

• Routes defined with post, put, patch, or delete that modify data but do not validate request.headers['X-CSRF-Token'].
• Endpoints that set or rely on session cookies without same_site: strict or secure: true.
• Absence of per-request tokens or custom headers that an attacker cannot read via a cross-origin script due to CORS restrictions.

middleBrick’s LLM/AI Security checks are not relevant to CSRF, but its standard scans include method-level and parameter-level analysis against the unauthenticated API surface. The scanner correlates findings with the OpenAPI spec (if provided), resolving $ref definitions to ensure inherited routes and shared components are also evaluated. If you use the CLI, you can run middlebrick scan https://api.example.com to get a report listing any CSRF-related findings with severity and remediation guidance.

Remediate CSRF in Grape by enforcing origin/referrer checks or adding anti-CSRF tokens for any state-changing endpoint. Because Grape often serves APIs consumed by browsers (e.g., paired with a JavaScript frontend), a robust approach is to require a custom header (such as X-CSRF-Token) that cannot be set cross-origin due to CORS rules, combined with same_site and secure cookie attributes.

Example of a CSRF-protected Grape endpoint using an origin check and a custom header:

class V1::Accounts < Grape::API
  format :json
  helpers do
    def verified_request?
      # Require Origin or X-CSRF-Token for state-changing methods
      %w[POST PUT PATCH DELETE].include?(request.request_method) ?
        (request.headers['Origin'].present? || request.headers['X-CSRF-Token'].present?) : true
    end
  end

  before do
    # Reject if missing valid origin for mutating endpoints
    error!('Invalid request origin', 403) unless verified_request?
  end

  desc 'Update email securely'
  params do
    requires :email, type: String, format?: URI::MailTo::EMAIL_REGEXP
  end
  put '/account/email' do
    current_user.update!(email: declared(params)[:email])
    { status: 'ok' }
  end
end

If your frontend and API share the same top-level domain, you can set session cookies with same_site: strict and secure: true and validate the Origin header on the server. For APIs used by third-party sites, require a per-request token in a header and avoid relying solely on cookies for authorization. middleBrick’s dashboard tracks these changes over time, and the Pro plan supports continuous monitoring and configurable alerts so you can detect regressions in CSRF protection as your API evolves.