Clickjacking in Sinatra with Firestore

Clickjacking is a client-side UI security issue where an attacker tricks a user into interacting with a hidden or disguised element inside an invisible or transparent page. When Sinatra serves pages that embed Firestore-backed data—such as a dashboard rendered from Firestore documents—the application can inadvertently expose interactive UI controls within an iframe that is not protected by anti-clickjacking defenses. If the Sinatra app embeds Firestore data in frames without setting appropriate HTTP response headers or without ensuring user intent, an attacker can overlay invisible controls or lure the user into clicking a benign page while malicious actions occur inside the embedded context.

Consider a Sinatra app that reads a Firestore document to render a user settings page and then includes an external analytics page in an iframe. Without a X-Frame-Options or Content-Security-Policy (CSP) frame-ancestors directive, the Sinatra page can be embedded anywhere. An attacker could craft a page that loads the Sinatra route inside a tiny, off-canvas iframe and overlay buttons such as "Delete Document" or "Update Permissions" on top of invisible Firestore-triggered actions. Because Firestore security rules operate server-side and do not enforce per-request UI intent, the browser will send credentials (cookies/session) with the request, and the action may execute if the user is authenticated.

Moreover, if the Sinatra application uses client-side JavaScript to directly interact with Firestore via an exposed API key or insecurely scoped rules, an attacker can simulate clicks inside the embedded context to trigger Firestore writes. For example, a Firestore listener attached to a user-specific path could be updated via a crafted form submission that originates from the clickjacked frame. The vulnerability is not in Firestore itself but in how Sinatra exposes and frames content that interacts with Firestore, especially when authentication/session cookies are sent automatically with cross-origin requests.

Real-world attack patterns mirror OWASP’s A05:2021 — Security Misconfiguration and A03:2021 — Injection (UI-level), and can be detected by scanners that test frame-busting, CSP, and X-Frame-Options headers. middleBrick’s 12 security checks include tests for improper framing and header misconfigurations that can expose clickjacking risks in Sinatra apps consuming Firestore data.

Remediation focuses on HTTP headers and UI design to prevent embedding, combined with secure Firestore access patterns in Sinatra. Do not rely on Firestore security rules alone to enforce UI intent; use defense-in-depth at the web layer served by Sinatra.

1. Set anti-clickjacking headers in Sinatra

Ensure every response includes X-Frame-Options and a strong CSP with frame-ancestors. In Sinatra, use a before filter to apply headers globally.

require 'sinatra'
require 'json'
require 'google/cloud/firestore'

before do
  # Prevent framing by any domain
  headers 'X-Frame-Options' => 'DENY',
          'Content-Security-Policy' => "default-src 'self'; frame-ancestors 'none'"
end

# Example route that reads from Firestore and renders a safe response
get '/user/:id/settings' do
  firestore = Google::Cloud::Firestore.new
  doc_ref = firestore.doc("users/#{params[:id]}")
  doc = doc_ref.get

  if doc.exists?
    settings = doc.data
    # Render settings safely; avoid embedding external frames
    erb :settings, locals: { settings: settings }
  else
    status 404
    { error: 'Settings not found' }.to_json
  end
end

The CSP header frame-ancestors 'none' prevents all framing; use frame-ancestors 'self' if you intentionally need to allow same-origin frames. Do not use ALLOW-FROM as it is obsolete and poorly supported.

2. Avoid embedding Firestore-driven pages in iframes

Design Sinatra views so that pages interacting with Firestore are never intended to be framed. If your app must include third-party content, prefer srcdoc or server-side includes rather than client iframes, and always apply CSP frame-ancestors explicitly for those routes.

3. Secure Firestore access in Sinatra

Use service account credentials server-side and avoid exposing API keys to the client. Validate and sanitize all inputs that are used to construct Firestore document paths.

# Server-side Firestore read with input validation
get '/document/:collection/:docId' do
  collection = params[:collection]
  doc_id = params[:docId]

  # Basic validation to prevent path traversal or unexpected reads
  unless collection.match?(Regexp.union(/^[a-z0-9_-]+$/i, '^[a-z0-9_-]+$')) && doc_id.match?(Regexp.union(/^[a-zA-Z0-9_-]+$/, '^[a-zA-Z0-9_-]+$/))
    status 400
    return { error: 'Invalid document path' }.to_json
  end

  firestore = Google::Cloud::Firestore.new
  doc_ref = firestore.doc("#{collection}/#{doc_id}")
  doc = doc_ref.get

  if doc.exists?
    content = doc.data
    # Safely render content; do not auto-execute code from Firestore
    erb :document, locals: { content: content }
  else
    status 404
    { error: 'Document not found' }.to_json
  end
end

These measures ensure that even if an attacker tricks a user into loading a crafted page, the Sinatra app will not allow clickjacking against Firestore-backed UI, and Firestore interactions remain server-side with strict input validation.