Broken Access Control in Hanami with Cockroachdb

Broken Access Control occurs when authorization checks are missing or incorrectly enforced, allowing attackers to access or modify resources they should not. In a Hanami application using Cockroachdb as the persistence layer, the risk arises from a mismatch between domain model rules and database permissions or from incomplete policy checks before data queries.

Hanami encourages explicit, role-based authorization in the application layer, but developers sometimes rely on Cockroachdb row-level security (RLS) alone or assume database permissions substitute for application checks. RLS in Cockroachdb can restrict rows by role, yet if Hanami services do not enforce ownership or tenant boundaries in every query, an authenticated user may manipulate identifiers to access another user’s records (a BOLA/IDOR pattern). For example, an endpoint like GET /api/invoices/:id might construct a query such as InvoicesRepository.find(id) without verifying that the current user’s account_id matches the invoice’s account_id. Cockroachdb will return the row if the SQL role has SELECT access, and Hanami will render it, creating an authorization bypass.

Another vector is privilege escalation via BFLA when admin-only operations are gated only by UI or route protection, while Cockroachdb connections use a shared, high-privilege role. If Hanami’s service objects do not re-validate permissions at the data layer, a user can invoke elevated actions by directly calling endpoints or manipulating parameters. In multi-tenant setups, missing tenant_id scoping in queries means a user could iterate over valid invoice IDs and read data from other tenants, with Cockroachdb returning results because the cluster’s network policies or TLS settings do not enforce tenant isolation at the SQL level.

Compliance mappings such as OWASP API Top 10 (broken access control) and SOC2 CC6.1 highlight the need for explicit authorization checks on every data access. middleBrick scans detect these patterns by correlating OpenAPI paths with runtime access attempts, showing missing authorization checks in endpoints that interact with Cockroachdb.

Remediation centers on enforcing authorization in Hanami service objects and repositories, ensuring tenant and ownership checks are part of every database query, and avoiding over-privileged database roles.

1. Always scope queries by tenant and owner

In repository methods, include the current user’s identifiers in the filter. This ensures that even if an ID is guessed, Cockroachdb returns no data unless the tenant and ownership match.

module Repositories
  class InvoiceRepository
    def self.find_by_tenant_and_user(id, tenant_id, user_id)
      DB[:invoices]
        .where(id: id, tenant_id: tenant_id, user_id: user_id)
        .limit(1)
        .to_a
        .first
    end
  end
end

2. Use explicit role checks in service operations

Before performing destructive actions, validate permissions in the service layer. Do not rely on Cockroachdb user permissions alone for business rules.

module Services
  class DeleteInvoiceService
    def initialize(invoice_repository: Repositories::InvoiceRepository)
      @invoice_repository = invoice_repository
    end

    def call(invoice_id, user)
      invoice = @invoice_repository.find_by_tenant_and_user(invoice_id, user.account_id, user.id)
      raise AuthorizationError unless invoice && user.can?(:manage_invoices, invoice)

      DB[:invoices].where(id: invoice_id).delete
      { success: true }
    end
  end
end

3. Avoid shared high-privilege roles for application connections

Configure Cockroachdb users per service role with least privilege. For read-heavy services, use a role with SELECT only on required tables; for write services, restrict to specific tables and avoid superuser privileges.

-- Example Cockroachdb role setup (run via migration or infra script) --
CREATE ROLE hanami_app_read;
GRANT SELECT ON TABLE invoices TO hanami_app_read;

CREATE ROLE hanami_app_write;
GRANT INSERT, UPDATE, DELETE ON TABLE invoices TO hanami_app_write;

-- Application connection strings should use these roles, not root or a wildcard admin.

4. Enforce tenant isolation in SQL policies

Use Cockroachdb’s table constraints and application-level defaults to prevent cross-tenant reads. Ensure every query includes tenant_id, and validate in migrations that indexes support tenant-based lookups.

-- Migration snippet to add tenant_id index for performance and isolation --
CREATE INDEX idx_invoices_tenant_id ON invoices (tenant_id, id);
-- This supports fast scoped queries and reduces accidental full-table scans.

5. Combine with middleBrick findings for continuous validation

Use the middleBrick CLI to scan your Hanami endpoints and verify that authorization findings are addressed. The CLI can be integrated into scripts to ensure that any new endpoints include required checks before merging.

# Scan an API endpoint from the terminal
middlebrick scan https://api.example.com