Auth Bypass in Hanami (Ruby)

Hanami is a lightweight Ruby web framework that follows a clear separation of concerns using the Rack API but implements its own routing and controller layers. When authentication logic is implemented directly within controllers without proper enforcement at the framework level, attackers can exploit structural inconsistencies to bypass security checks.

In particular, if an application uses a before filter incorrectly scoped or fails to validate session state across all request paths, an unauthenticated user may access protected endpoints. This is especially dangerous in Hanami because its architecture encourages minimal middleware usage, and developers often implement authentication manually using Rack sessions or custom gateways.

Consider a typical Hanami controller action that should only be accessible to authenticated users:

class Api::V1::DashboardController < Hanami::Controller
  include Authenticatable

  def index
    render json: { user: current_user.attributes }
  end
end

Here, Authenticatable is a module that includes a current_user method, which may raise an exception or return nil if no session exists. If this method is not wrapped with proper authorization logic, and if the route does not enforce authentication via Hanami's routing DSL, an attacker can craft a direct request to /api/v1/dashboard without cookies or headers, potentially bypassing session validation entirely.

Moreover, Hanami's routing system allows multiple entry points for the same logical resource. If a developer mistakenly defines both /auth/dashboard and /dashboard as separate routes, and only protects one, the other may be inadvertently exposed. This kind of path confusion is a known vector in Ruby applications where RESTful conventions are not strictly enforced.

Real-world parallels exist in CVE histories where frameworks like Sinatra (which influenced Hanami) had vulnerabilities due to missing default scoping. For example, CVE-2015-3152 involved session fixation in a Sinatra app where route guards were conditionally applied. While not directly replicable in Hanami, the principle remains: if authentication logic is not centralized and consistently applied across all actions, attackers can probe for blind spots.

Additionally, Hanami's lack of built-in CSRF protection means developers must manually add anti-forgery tokens. If forgotten, an attacker can trick an authenticated user into making state-changing requests — another form of session-based bypass. This is critical when building APIs that rely on session cookies without proper SameSite attributes or anti-automation headers.

In summary, auth bypass in Hanami with Ruby stems from inconsistent application of authentication guards, improper scoping of before filters, and fragmented route definitions. These are not framework flaws per se, but architectural vulnerabilities born from manual implementation without guardrails.

To prevent auth bypass in Hanami applications, developers must enforce authentication at the earliest possible point and ensure it cannot be skipped via route misconfiguration or session manipulation.

One effective pattern is to use Hanami's before filter in a base controller that all protected controllers inherit from. This ensures every action in the hierarchy checks for authentication before execution:

class ApplicationController < Hanami::Controller
  before :authenticate!

  private

  def authenticate!
    unless session[:user_id]
      response.status = 401
      response.body = { error: 'Unauthenticated' }.to_json
      true # halt further processing
    end
  end
end

This approach centralizes the check and prevents individual controllers from accidentally omitting it. Every subclass inherits the behavior, reducing the chance of omission.

For stronger enforcement, combine this with Hanami's routing constraints. Instead of defining public routes alongside protected ones, group them under a use block in the router:

require 'hanami/router'

router = Hanami::Router.new do
  # Protected routes require authentication
  paths '/api/v1/dashboard/*' do
    run Dashboard::API
    # Any request to this path automatically requires authentication
  end

  # Optional: define public routes separately
  get '/health', to: HealthController
end

This ensures that even if a controller forgets to include a before filter, the router-level path binding may still enforce protection — though this should not replace controller-level checks.

Another layer of defense is to validate session integrity. Always regenerate session IDs after login to prevent fixation, and use secure, HttpOnly, SameSite=Strict cookies:

# In a Rack middleware or Hanami setup
response.set_cookie(:session, new_session_id, { secure: true, httponly: true, same_site: :strict })

Additionally, use strong parameter validation to prevent injection via headers or query strings that might interfere with authentication state. For example, never trust request.GET['admin'] as a bypass vector:

# Reject suspicious query patterns early
unless request.env['HTTP_X_SKIP_AUTH'].to_s.match?(/^(true|1|yes)$/) && !authenticated?
  halt 403, { error: 'Access denied' }.to_json
end

These practices align with OWASP API Top 10 category A01:2023 (Broken Object Level Authorization) and A07:2023 (Identification and Authentication Failures). By enforcing authentication at the framework level and avoiding ad-hoc checks, Ruby developers using Hanami can eliminate entire classes of bypass vulnerabilities.