Clickjacking in Grape with Bearer Tokens

Clickjacking is a client-side UI redress attack where an attacker tricks a user into interacting with a hidden or disguised element inside an invisible or obscured frame. When an API designed with Grape uses bearer tokens for authentication but relies solely on token validation without anti-clickjacking protections, the API can indirectly enable or fail to prevent abuse via embedded contexts. Grape is a REST-like micro-framework for Ruby, commonly used to build APIs that return JSON or HTML. If a Grape endpoint serves HTML (for example, a dashboard or embedded widget) and includes bearer token-based authorization without explicit frame-busting or CSP frame-ancestor rules, an attacker may embed the endpoint in an <iframe> or <frame> and lure a authenticated user into clicking through the UI while the bearer token is present in headers or stored client-side.

In this combination, the risk is not that the bearer token itself is clickjacked — tokens are not visible elements — but that the authenticated session or token-bearing UI can be manipulated. For example, an attacker might host a malicious page containing an invisible iframe that points to a Grape API route that returns an HTML admin action (e.g., approving a transaction or toggling a setting). If the user is already authenticated via a bearer token stored in a cookie or sent in headers, and the Grape API does not enforce X-Frame-Options or Content Security Policy (CSP) frame-ancestors, the endpoint may render inside the attacker’s frame. The user’s click coordinates can be mapped to the hidden frame’s elements, leading to unauthorized actions under the context of the valid bearer token.

Grape APIs that return HTML representations (rather than pure JSON APIs consumed by secure clients) are more exposed when bearer tokens are used for authorization but framing protections are absent. Even if the API relies on bearer tokens passed in the Authorization header, a compromised or malicious page can still embed these routes if the server does not explicitly prohibit framing. This is especially relevant when token handling is done via cookies with relaxed same-site attributes, because the browser will automatically include credentials in the request initiated by the frame. Without explicit mitigations, an attacker can craft a phishing page that embeds the Grape endpoint and induces the victim to perform state-changing actions while the bearer token is presented automatically by the browser.

Real-world attack patterns mirror classic clickjacking scenarios, but with API-focused contexts: an attacker might use social engineering to get an authenticated user to visit a page that embeds a Grape-powered financial or admin endpoint. The middleware does not inspect frame context, and the bearer token is accepted, allowing unauthorized operations. Although Grape itself does not enforce browser security headers, the application stack must compensate with strong CSP frame-ancestors directives and X-Frame-Options to ensure that endpoints returning HTML cannot be embedded. For JSON-only APIs, clickjacking is less relevant, but if any HTML rendering occurs with bearer token authorization, the absence of frame restrictions creates a viable vector.

Remediation focuses on preventing framing of any HTML responses and ensuring bearer tokens are not automatically sent in cross-origin contexts where clickjacking could be relevant. Below are concrete code examples for a Grape API that show how to add security headers and frame-busting considerations.

1. Setting CSP frame-ancestors and X-Frame-Options in Grape

Ensure that any endpoint that returns HTML includes strong framing protections. Use rack-protection or manually set headers. Here is an example using a Grape API class:

class MyAPI < Grape::API
  format :json

  # For HTML responses, add this before your route or use a before filter
  before do
    # Only set headers for HTML responses; keep JSON responses lean
    if env['HTTP_ACCEPT']&.include?('text/html')
      header['Content-Security-Policy'] = "default-src 'self'; frame-ancestors 'none';"
      header['X-Frame-Options'] = 'DENY'
    end
  end

  get :public_data do
    # If this returns HTML, it will be protected; prefer JSON for APIs
    { message: 'No HTML here' }
  end
end

If you serve HTML views through Grape (e.g., with grape-entity or custom renderers), ensure the CSP header explicitly denies framing by setting frame-ancestors 'none'. For legacy browser support, also include X-Frame-Options: DENY.

2. Bearer token handling best practices to reduce clickjacking impact

Ensure bearer tokens are transmitted securely and are not automatically included in cross-origin requests initiated by attacker-controlled frames. Use SameSite attributes and avoid cookie storage for tokens when possible. If tokens must be stored in cookies (e.g., for JavaScript clients), set SameSite=Lax or Strict and ensure Secure and HttpOnly are set where appropriate. Example of secure token cookie settings in a complementary Rack middleware or session setup:

# config/initializers/session_store.rb or equivalent
Rails.application.config.session_store :cookie_store,
  key: '_my_app_session',
  same_site: :strict,
  secure: Rails.env.production?,
  httponly: true

For APIs that accept bearer tokens via the Authorization header, the browser will not automatically include them in cross-origin iframe requests unless explicitly programmed (e.g., with fetch credentials). This reduces the risk of token leakage via clickjacking. Still, enforce strict CSP frame-ancestors to prevent any HTML views from being embedded.

3. Example of a protected route that returns JSON (recommended)

For typical Grape APIs that are consumed by clients and do not render HTML, clickjacking is less of a concern, but framing protections can still be applied globally to prevent misuse:

class SecureAPI < Grape::API
  format :json

  # Global before block to set security headers for all responses
  before do
    header['Content-Security-Policy'] = "default-src 'none'; frame-ancestors 'none';"
    header['X-Content-Type-Options'] = 'nosniff'
    header['Referrer-Policy'] = 'no-referrer-when-downgrade'
  end

  get :secure_endpoint do
    { status: 'ok', authenticated: true }
  end
end

These headers ensure that even if an endpoint is mistakenly rendered in a browser context, it cannot be framed. Combine this with proper CORS configuration to limit origins that can interact with your API.