Cross Site Request Forgery in Grape with Cockroachdb

Cross Site Request Forgery (CSRF) in a Grape API backed by Cockroachdb arises when state-changing HTTP requests (POST, PUT, PATCH, DELETE) can be forged by an attacker without the user’s consent. Because Grape is an API framework that often serves JSON and does not enforce browser-origin protections like SameSite cookies by default, endpoints that rely on session cookies for authorization can be vulnerable if they lack anti-CSRF tokens or explicit origin checks.

With Cockroachdb, a distributed SQL database commonly used for multi-region resilience and strong consistency, the risk centers on how application-level authorization is enforced rather than on the database itself. If a Grape endpoint uses cookie-based session authentication (for example, a session ID stored in a cookie) and performs SQL operations against Cockroachdb without verifying the request origin or including a CSRF token, an attacker can trick a logged-in user into submitting a crafted request. Example scenario: an authenticated user visits a malicious site that sends a DELETE /api/v1/accounts/:id request via image tag or form submission. If the Grape endpoint only checks session presence and executes Cockroachdb SQL like DELETE FROM accounts WHERE id = $1 using the user’s session identity, the operation will succeed, leading to unauthorized data modification.

The exposure is amplified when endpoints do not validate the request’s Referer or Origin headers and when Cockroachdb transactions are used without idempotency keys or request verification. Since Cockroachdb supports serializable isolation, race conditions are rare, but CSRF remains a top-level business logic issue. Attack patterns include forged authenticated requests from compromised subdomains or malicious sites that share authentication cookies. OWASP API Top 10 identifies broken object-level authorization and missing access controls as common API risks; CSRF fits when trust is placed solely on cookies without additional checks.

To detect such issues, middleBrick scans unauthenticated attack surfaces and can flag endpoints that accept state-changing methods without CSRF protections. It checks authentication mechanisms, input validation, and whether responses inadvertently expose tokens or sensitive data. Even without authenticated scans, unauthenticated probes can identify missing anti-CSRF safeguards in public-facing endpoints.

Remediation focuses on ensuring each state-changing request is explicitly authorized and cannot be triggered by a third-party site. Implement anti-CSRF tokens or require custom headers that cannot be set cross-origin (e.g., X-Requested-With or a bearer token in Authorization). For APIs, prefer token-based authentication (e.g., JWT in the Authorization header) and validate origins or use SameSite cookie attributes where cookies are necessary.

In Grape, you can enforce CSRF protection by adding a before filter that validates a token or a custom header for mutating methods. Below is a concrete example of a Grape API with Cockroachdb integration that uses a CSRF token stored in a session cookie and verified on state-changing routes.

require 'grape'
require 'pg' # Cockroachdb PostgreSQL wire-compatible driver
require 'securerandom'

class CsrfProtection < Grape::API
  before do
    # For mutating methods, ensure a CSRF token is present and matches the session token
    if %w[POST PUT PATCH DELETE].include?(request.request_method)
      token = env['rack.session']&.[](:csrf_token)
      header_token = request.env['HTTP_X_CSRF_TOKEN']
      halt 403, { error: 'Invalid CSRF token' }.to_json unless token && token == header_token
    end
  end

  helpers do
    def db
      @db ||= PG.connect(
        host: ENV['COCKROACHDB_HOST'],
        port: ENV.fetch('COCKROACHDB_PORT', 26257),
        dbname: ENV['COCKROACHDB_DB'],
        sslmode: 'require'
      )
    end

    def generate_csrf_token
      SecureRandom.hex(32)
    end
  end

  before do
    # Ensure session has a CSRF token for the session lifecycle
    env['rack.session'] ||= {}
    env['rack.session'][:csrf_token] ||= generate_csrf_token
  end

  resource :accounts do
    desc 'Update account, requires CSRF token'
    params do
      requires :id, type: Integer, desc: 'Account ID'
      requires :balance, type: Float, desc: 'New balance'
    end
    put ':id' do
      token = request.env['HTTP_X_CSRF_TOKEN']
      halt 403, { error: 'CSRF token missing' }.to_json unless token == env['rack.session'][:csrf_token]

      result = db.exec_params('UPDATE accounts SET balance = $1 WHERE id = $2', [params[:balance], params[:id]])
      { status: 'updated', id: params[:id] }
    rescue PG::Error => e
      error!({ error: e.message }, 500)
    end

    desc 'Delete account, requires CSRF token'
    params do
      requires :id, type: Integer, desc: 'Account ID'
    end
    delete ':id' do
      halt 403, { error: 'CSRF token missing' }.to_json unless request.env['HTTP_X_CSRF_TOKEN'] == env['rack.session'][:csrf_token]

      db.exec_params('DELETE FROM accounts WHERE id = $1', [params[:id]])
      { status: 'deleted', id: params[:id] }
    rescue PG::Error => e
      error!({ error: e.message }, 500)
    end
  end
end

Key points: the session stores a cryptographically random CSRF token; mutating endpoints require the token in the X-CSRF-Token header; Cockroachdb commands are parameterized to avoid SQL injection. For SPAs, consider JSON-only APIs with JWT in the Authorization header and CORS restricted to trusted origins, which avoids reliance on session cookies and simplifies CSRF mitigation.