Clickjacking in Rails with Basic Auth

Clickjacking is a client-side injection attack where an attacker tricks a user into clicking or interacting with a hidden UI element inside an invisible or disguised frame. When Basic Authentication is used in a Rails application, embedding the application inside an iframe can couple the authentication credentials with the UI interaction in a dangerous way. Basic Auth credentials are sent via the Authorization header on every request made by the browser for that origin, including subresource and frame requests. If the app’s pages are served without explicit framing protections and also rely on Basic Auth, an attacker can load the app’s sensitive actions (for example, a destructive POST or a configuration change) inside an invisible iframe and overlay interactive elements on top of them. The user, already authenticated via Basic Auth, may inadvertently activate those controls, causing unwanted state changes or data exposure.

Rails by default does not prevent framing. Without a Content Security Policy (CSP) frame-ancestors directive or an explicit X-Frame-Options header, any page protected by HTTP Basic Auth can be embedded. Because Basic Auth credentials are sent automatically by the browser, the authenticated session is preserved inside the embedded context. This combination means an attacker can craft a page that loads https://app.example.com/admin/settings (protected by Basic Auth) inside a frame and overlay a transparent button positioned over a ‘Delete User’ or ‘Save Configuration’ form submit. When the user clicks what appears to be a benign element on the attacker’s page, the hidden submit is activated with the user’s Basic Auth credentials, leading to unauthorized state changes.

Additionally, browser behavior around caching and credential persistence can amplify the risk. Once a user has supplied Basic Auth credentials for a realm, the browser may reuse them for subsequent requests to the same origin within the same browsing session, even inside iframes. This persistence means a single successful authentication can expose multiple pages to clickjacking until the session ends. Furthermore, if the application embeds sensitive UI components inside iframes intentionally or via third-party integrations, and those frames are clickjacked, the security boundary between the embedded content and the host page is violated. The remedy is not to rely on security through obscurity or UI framing decisions alone, but to enforce strict framing rules and ensure that sensitive operations require explicit, user-driven context that cannot be hijacked by overlays.

Remediation centers on two controls: preventing framing and strengthening authentication flow. The primary defense is to ensure that pages protected by HTTP Basic Auth are not embeddable. In Rails, you can set the X-Frame-Options header and a strict CSP frame-ancestors directive. For applications that do not require framing at all, a global approach is appropriate. For applications that must embed certain views, use a restrictive CSP and ensure that sensitive actions are protected with additional confirmation steps that cannot be triggered by user interaction in an ancestor context.

Example: Setting headers in a Rails controller to prevent framing and enforce CSP:

class ApplicationController < ActionController::Base
  before_action :set_frame_options_header
  before_action :set_csp_header

  private

  def set_frame_options_header
    response.headers["X-Frame-Options"] = "DENY"
  end

  def set_csp_header
    response.headers["Content-Security-Policy"] = "frame-ancestors 'none';"
  end
end

If you must allow framing for specific, non-sensitive views, scope the CSP to particular paths and avoid applying it globally to authenticated endpoints. For Basic Auth–protected endpoints, prefer form-based authentication with CSRF tokens, which integrates cleanly with Rails’ authenticity token mechanisms. When Basic Auth is required (for example, for API clients or limited admin interfaces), ensure that the realm is narrow and that sensitive actions include an additional CSRF-like confirmation that cannot be triggered cross-origin.

Example: Using HTTP Basic Auth in a controller with explicit realm and ensuring sensitive actions require additional verification:

class AdminController < ApplicationController
  http_basic_authenticate_with name: "admin", password: "secret", realm: "Admin Area"

  def sensitive_action
    # Require explicit confirmation token or re-auth for critical operations
    unless params[:confirmation_token] == current_user_confirmation_token
      render plain: "Forbidden: additional confirmation required", status: :forbidden
      return
    end
    # Proceed with sensitive logic
  end
end

Finally, validate that no page protected by Basic Auth embeds sensitive forms inside iframes without additional safeguards. Combine header defenses with server-side checks that verify the request’s `Referer` or use origin checks where appropriate, and educate users that Basic Auth–protected pages should not be shared or embedded. When feasible, migrate high-risk interfaces to token-based authentication with CSRF protection to avoid the inherent risks of embedding credentials in headers across frames.