Clickjacking in Sinatra (Ruby)

Clickjacking is a client-side web security vulnerability where an attacker tricks a user into clicking on a hidden or disguised UI element inside an invisible or transparent iframe. In a Sinatra application written in Ruby, this commonly occurs when pages are served without explicit framing protections. Sinatra does not set any default HTTP headers to prevent embedding, so unless the developer explicitly configures the app, pages can be loaded into an iframe on a malicious site.

An attacker might host a page that overlays invisible or opaque UI controls (e.g., a malicious button styled to look inert) atop a legitimate action like confirming a transaction or updating an email. The user believes they are interacting with the attacker’s page, but their click is captured by the embedded target application while the visual context is controlled by the attacker. Ruby code that renders views without anti-clickjacking safeguards effectively exposes the app to this behavior, especially when combined with social engineering that convinces the user to visit the attacker’s page.

Sinatra’s lightweight nature means developers often add routes and render ERB or other templates without considering frame-related headers. If the application includes sensitive actions accessible while authenticated (e.g., changing a password or authorizing OAuth), and those pages can be framed, the risk increases. Attack vectors such as CSRF rely on the browser automatically sending cookies; clickjacking layers deception on top of that by manipulating what the user thinks they are clicking. The combination of Ruby, Sinatra’s minimal defaults, and missing frame-ancestor policies creates conditions where an unauthenticated or authenticated attacker can coerce users into performing unintended actions via embedded content.

Because middleBrick scans the unauthenticated attack surface and includes security checks such as Property Authorization and Input Validation, it can surface missing anti-clickjacking protections as findings. The scanner evaluates response headers and rendered behaviors, highlighting whether X-Frame-Options or Content-Security-Policy frame-ancestors are absent. This is particularly relevant for Sinatra apps that serve administrative interfaces or transactional pages without explicit framing rules, as those endpoints often become high-impact targets for clickjacking.

Remediation centers on adding HTTP headers that prevent framing, and ensuring sensitive pages explicitly opt out of being embedded. In Ruby/Sinatra, you can set headers globally in the main application file or per route. Below are concrete, idiomatic examples that you can apply directly.

1. Global protection with X-Frame-Options

The simplest and widely supported approach is to set X-Frame-Options. In Sinatra, use a before filter to apply it to all responses unless a route opts out.

require 'sinatra'

before do
  response['X-Frame-Options'] = 'DENY'
end

get '/' do
  'Home page — cannot be framed'
end

get '/public-page' do
  # If you need this page to be embeddable, set a more permissive value:
  # response['X-Frame-Options'] = 'SAMEORIGIN'
  'Public content'
end

2. Granular control with Content-Security-Policy frame-ancestors

For modern browsers, use Content-Security-Policy with frame-ancestors to allow specific origins. This is more flexible than X-Frame-Options and can be combined if needed (browsers typically honor CSP over X-Frame-Options when both are present).

configure do
  # Deny all framing
  set :protection, { frame_options: :deny }
end

# Or set via header directly for finer control:
before do
  # Allow framing only from the same origin
  content_security_policy do |p|
    p.frame_ancestors %w['self']
  end
end

get '/settings' do
  'Sensitive settings — safe from clickjacking'
end

3. Context-specific exemptions

If a particular route must be embedded (for example, an internal dashboard embedded by a trusted partner), explicitly set a permissive policy only for that route and keep the default restrictive behavior elsewhere.

get '/embedded-report' do
  response['Content-Security-Policy'] = "frame-ancestors 'self' https://partner.example.com;"
  'Report that can be safely embedded'
end

4. Combining with authenticity tokens for state-changing actions

To further reduce risk, ensure forms that perform state changes include authenticity or anti-CSRF tokens. While this does not stop clickjacking alone, it complements framing protections by preventing successful forged requests if the user is tricked into interacting with an invisible submit.

enable :sessions

helpers do
  def csrf_token
    session[:csrf_token] ||= SecureRandom.hex(16)
  end

  def csrf_tag
    "<input type='hidden' name='csrf_token' value='#{csrf_token}'>"
  end
end

get '/form' do
  erb <<-ERB
    <form action='/submit' method='POST'>
      #{csrf_tag}
      <button type='submit'>Submit</button>
    </form>
  ERB
end

post '/submit' do
  halt 403, 'Invalid CSRF token' unless params['csrf_token'] == session[:csrf_token]
  'Action processed safely'
end

5. Testing your protections

After applying headers, verify using a simple curl command and by scanning with tools that inspect framing behavior. middleBrick can be used to confirm the presence and correctness of these headers across your endpoints as part of routine checks.