Cross Site Request Forgery in Grape with Mongodb

Cross Site Request Forgery (CSRF) in a Grape API backed by Mongodb arises when state-changing HTTP requests (POST, PUT, PATCH, DELETE) rely only on cookies for session-like identification without anti-CSRF tokens or equivalent validation. In this stack, the client stores a session cookie (or a JSON Web Token used as a bearer token stored in a cookie), and the Grape app trusts that cookie to identify a user and apply operations against Mongodb. An attacker can craft a malicious site that triggers requests from the victim’s browser to the Grape endpoint. Because the browser automatically includes the cookie, the request is authenticated from the server’s perspective, but the intent is forged by the attacker.

Consider a Grape resource that deletes or updates a user record in Mongodb based on an identifier provided in the request body or URL. If the endpoint does not verify that the authenticated user intended this specific action, an attacker can induce a logged-in user to visit a page like https://api.example.com/users/12345/delete or submit a form with malicious parameters. The Mongodb operation executes under the permissions of the authenticated user’s token, potentially deleting or modifying data the user did not authorize. This becomes more impactful when combined with other issues such as IDOR, where the attacker can change the identifier to target other users’ documents, but even without IDOR, CSRF enables unauthorized actions on behalf of a trusted user.

The vulnerability is not inherent to Mongodb but is exposed by the API design in Grape. For example, if the Grape app decodes a JWT from a cookie and uses the subject to build Mongodb queries without additional authorization checks per request, the attack surface is wide. Real-world attack patterns include forged AJAX requests from an authenticated session or image tags that trigger GET-based state changes (if unsafe methods are improperly allowed). While GET requests should not change state, misconfigured routes sometimes do, making CSRF viable. The stack also increases risk if tokens are long-lived and lack proper binding, allowing replay across tabs or origins.

To map this to frameworks, findings may align with OWASP API Top 10 A05:2023 — Broken Function Level Authorization, where missing authorization validation at the function level intersects with CSRF-style forged requests. PCI-DSS and SOC2 controls also expect protection against unauthorized commands, and CSRF mitigation contributes to meeting those requirements. middleBrick scans detect these patterns by correlating authentication usage in Grape routes with the presence of state-changing methods and insufficient anti-CSRF controls, reporting the issue with severity and remediation guidance.

Remediation focuses on ensuring every state-changing operation in Grape is bound to the authenticated user’s identity and protected by anti-CSRF practices. Use strong anti-CSRF tokens for browser-based clients (e.g., synchronizer token pattern) or require custom headers (e.g., X-Requested-With) for API clients, and avoid relying solely on cookies for sensitive actions. In Mongodb queries, always scope by user identity and validate ownership server-side.

Example: A safe Grape endpoint that deletes a user document by ID with ownership check and header-based CSRF protection.

require 'grape'
require 'mongo'

class UserResource < Grape::API
  helpers do
    def current_user
      @current_user ||= begin
        token = request.headers['Authorization']&.split(' ')&.last
        return nil unless token
        # verify token and fetch user; simplified example
        users_collection.find({ session_token: token }).first
      end
    end

    def require_header_csrf
      halt 403, { error: 'Invalid CSRF token' }.to_json unless request.headers['X-CSRF-Token'] == request.cookies['csrf_token']
    end

    def users_collection
      Mongo::Client.new(['127.0.0.1:27017'], database: 'app_db')[:users]
    end
  end

  before { require_header_csrf if %w[POST PUT PATCH DELETE].include?(request.request_method) }

  desc 'Delete a user document by ID with ownership and CSRF checks'
  params do
    requires :id, type: String, desc: 'User document ID'
  end
  delete ':id' do
    user = current_user
    halt 401, { error: 'Unauthorized' }.to_json unless user

    result = users_collection.find_one_and_delete(
      { _id: BSON::ObjectId(params[:id]), user_id: user['_id'] }
    )
    if result
      { status: 'deleted' }.to_json
    else
      halt 404, { error: 'Not found or insufficient permissions' }.to_json
    end
  end
end

Key points in the example:

• current_user derives identity from a token (e.g., JWT or session token stored securely) and fetches the user document from Mongodb to validate presence.
• Each state-changing request requires a CSRF token passed in a custom header (X-CSRF-Token) and compared with a per-session token stored in a cookie, mitigating forged requests from external origins.
• The Mongodb query scopes by both the provided document ID and the authenticated user’s ID (user_id: user['_id']), preventing IDOR by ensuring users can only affect their own documents.
• Use find_one_and_delete with an ObjectId to avoid injection and ensure atomicity; always validate and sanitize inputs before constructing queries.

For non-browser clients (e.g., mobile or third-party integrations), consider requiring an additional custom header or an anti-CSRF token in the request body, and enforce strict CORS policies. Rotate tokens and use short-lived credentials where possible. middleBrick’s GitHub Action can be added to CI/CD pipelines to automatically check for such CSRF-related findings and fail builds if the risk score drops below your chosen threshold.