Beast Attack in Grape with Bearer Tokens

A Beast Attack (BOLA/IDOR) in a Grape API that relies on Bearer Tokens occurs when an endpoint uses a token to identify the subject but does not enforce ownership or authorization checks on the targeted resource. For example, an endpoint like /api/v1/users/:user_id/profile may authenticate the request with a Bearer Token, yet fail to verify that the authenticated subject matches the provided user_id. This mismatch allows an attacker to manipulate the ID parameter and access or modify another user’s profile, a classic BOLA/IDOR pattern.

Bearer Tokens are often issued with claims such as sub (subject) and scope, but if the server uses only the token for authentication and does not cross-check the token’s subject against the resource identifier, the authorization boundary breaks. In Grape, this can happen when developers rely on a helper like current_user derived from the token but then directly use user-supplied IDs in queries without scoping to current_user. For instance, fetching User.find(params[:id]) instead of current_user.profile exposes the vulnerability because any valid Bearer Token can be paired with any numeric ID to traverse records.

The attack surface is expanded when token introspection or validation is incomplete. If the API validates the token signature but does not bind the token’s claims to the request path, an attacker can use a single compromised token to iterate over IDs and enumerate accessible resources. This is particularly risky in endpoints that return sensitive data (e.g., PII, billing details) or allow mutations (e.g., updating email or role). Because Grape allows flexible route definitions, developers must explicitly scope every data access to the authenticated subject to prevent Beasts Attacks.

Real-world parallels include cases where token-based APIs lack proper ownership checks, leading to unauthorized reads and writes. Although this is not a token format flaw, it is an authorization design flaw that Bearer Tokens can amplify when scopes and subject claims are not enforced at the resource level. The risk is elevated in microservice architectures where multiple services share token validation logic but may implement authorization inconsistently.

middleBrick’s BOLA/IDOR checks operate in parallel with other security validations and can detect these authorization gaps during an unauthenticated scan. By analyzing the OpenAPI spec and runtime behavior, the scanner flags endpoints where resource identifiers are not properly constrained by the token’s subject, providing prioritized findings with remediation guidance. This helps teams identify Beasts Attack vectors specific to their Grape implementations before attackers can exploit them.

To remediate Beasts Attack risks in Grape when using Bearer Tokens, always scope data access to the authenticated subject. Instead of trusting user-supplied IDs directly, derive resources from the token’s subject and avoid using raw IDs in queries. Below are concrete, safe patterns.

1. Authenticate with Bearer Token and scope to the subject

Use a helper that extracts the subject from the token and ensures all operations are performed on that subject.

module API
  module V1
    class Profiles < Grape::API
      helpers do
        def current_user
          @current_user ||= begin
            token = request.env['HTTP_AUTHORIZATION']&.split(' ')&.last
            subject = token ? decode_jwt_subject(token) : nil
            subject ? User.find_by(sub: subject) : nil
          end
        end

        def decode_jwt_subject(token)
          # Use a library like jwt to verify and decode
          decoded = JWT.decode(token, Rails.application.secrets.secret_key_base, true, { algorithm: 'HS256' })
          JSON.parse(decoded.first['payload'])['sub']
        rescue JWT::DecodeError
          nil
        end
      end

      before { authenticate! }

      get '/profile' do
        present current_user.profile, with: Entities::Profile
      end
    end
  end
end

2. Avoid user-provided IDs for sensitive resources; derive from subject

Never allow an ID from params to directly look up a record that belongs to a user. Instead, scope the query to the authenticated subject.

get '/users/:user_id/profile' do
  user = User.find_by(sub: params[:user_id]) # Unsafe: relies on client-supplied ID
  # Risky: attacker can change :user_id to access another user
end

# Safe version
get '/profile' do
  profile = current_user.profile
  present profile, with: Entities::Profile
end

# If you must accept an ID, enforce ownership
put '/users/:user_id' do
  user = User.find_by(sub: params[:user_id])
  error!('Forbidden', 403) unless user && user == current_user
  user.update!(user_params)
  present user, with: Entities::UserPublic
end

3. Validate token claims and enforce authorization at the resource level

Ensure that token validation includes checks on scopes and that every data access is filtered by the subject derived from the token.

helpers do
  def authorize_user!(user_id)
    token_subject = decode_jwt_subject(request.env['HTTP_AUTHORIZATION']&.split(' ')&.last)
    error!('Unauthorized', 401) unless token_subject
    error!('Forbidden', 403) unless token_subject == user_id.to_s
  end
end

get '/users/:id' do
  authorize_user!(params[:id])
  user = User.find(params[:id])
  present user, with: Entities::UserPublic
end

These patterns ensure that Bearer Tokens are used not only for authentication but also for enforcing authorization boundaries, effectively mitigating Beasts Attack risks in Grape APIs. middleBrick’s CLI tool can help verify that such scoping is consistently applied across endpoints.