Identification Failures in Hanami with Dynamodb

Identification failures occur when an application fails to reliably and securely confirm the identity of a subject or distinguish one resource from another. In a Hanami application using Amazon DynamoDB as the persistence layer, this risk pattern commonly emerges from a mismatch between how entities are looked up and how authorization decisions are made. Because DynamoDB is a schemaless, key-value store, the onus is on the application to enforce strict identification and ownership checks; without them, attackers can manipulate identifiers to access other users' data.

Consider a Hanami resource such as a Document. If the route relies on a user-supplied document_id (e.g., /documents/:id) and the backend retrieves the item directly from DynamoDB without validating that the user_id in the token matches the user_id stored with the item, this is a classic BOLA/IDOR scenario. The DynamoDB query might use a GetItem or a Query on a Global Secondary Index (GSI) that includes user_id as a partition or sort key, but if the application omits the ownership filter, one user can substitute any known ID and read or modify another user’s document. This is an identification failure because the system does not properly bind the requester’s identity to the requested resource.

In Hanami, the service object or repository pattern is typically used to encapsulate data access. An insecure implementation might look up an item by ID and return it directly, while a secure implementation would scope the query to the current user. For example, a vulnerable approach might be:

class DocumentRepository
  def find(id)
    dynamodb.get_item(
      table_name: 'documents',
      key: { id: id }
    )
  end
end

An attacker who knows or guesses another user’s id can call this method and obtain data they should not see. In contrast, a secure query binds the user context to the DynamoDB key or index key:

class DocumentRepository
  def find_for_user(id, user_id)
    dynamodb.query(
      table_name: 'documents',
      index_name: 'user_id-index',
      key_condition_expression: 'user_id = :uid AND id = :doc_id',
      expression_attribute_values: {
        ':uid' => user_id,
        ':doc_id' => id
      }
    )
  end
end

DynamoDB’s lack of native referential integrity amplifies identification failures if the application does not enforce ownership at the data-access layer. Since Hanami does not impose a default ORM-level ownership model, developers must explicitly scope every read and write. Another subtle risk involves secondary indexes: if a GSI’s partition key does not include the user context, a Query could return items across users, enabling horizontal privilege escalation. For example, querying a status-index without a user filter could expose items belonging to other users if the index key does not incorporate user_id. Proper identification in this context means ensuring that every DynamoDB operation includes the user identifier as a mandatory filter, either as part of the key condition or as an expression attribute value that is compared post-retrieval.

Additionally, identification failures can manifest in how Hanami resolves associations. If a Hanami entity includes a user_id property and the service layer loads related data by ID without re-verifying ownership, the boundary between identification and authorization blurs. For instance, loading a Comment by ID and then checking whether its user_id matches the current user after the fact is less secure than including the user ID in the key expression up front. This aligns with the principle of failing securely: the earlier the identification check is embedded in the data access pattern, the smaller the attack surface. In DynamoDB, this means designing primary keys and indexes so that user-specific queries cannot accidentally leak data, and ensuring that Hanami’s domain logic enforces identification before any business rules are applied.

Remediation focuses on enforcing strict identification at the data-access layer and validating that every DynamoDB operation is scoped to the requesting user. Below are concrete patterns and code examples for a Hanami application.

• Use composite keys with user context: Design your DynamoDB table so that the partition key includes the user identifier, or create a GSI where the partition key is user_id. This ensures queries are naturally scoped and makes it difficult to access another user’s items by ID alone.
• Always include the user ID in key conditions: When using Query, include the user identifier in the key condition expression and avoid relying on filters that only exclude mismatches after the query.
• Validate ownership before and after retrieval: Even when scoping queries, compare the returned item’s user ID with the authenticated user’s ID as an additional safeguard.

Secure Hanami repository example with DynamoDB:

class SecureDocumentRepository
  def initialize(user_id)
    @user_id = user_id
  end

  def find(id)
    resp = dynamodb.query(
      table_name: 'documents',
      index_name: 'gsi_user_id_id',
      key_condition_expression: 'user_id = :uid AND id = :doc_id',
      expression_attribute_values: {
        ':uid' => @user_id,
        ':doc_id' => id
      }
    )
    items = resp.items
    raise NotFound if items.empty?
    # Optional: double-check ownership if not enforced by key
    raise Unauthorized if items.first['user_id'] != @user_id
    items.first
  end

  def list
    dynamodb.query(
      table_name: 'documents',
      index_name: 'gsi_user_id_id',
      key_condition_expression: 'user_id = :uid',
      expression_attribute_values: { ':uid' => @user_id }
    )
  end
end

In this example, the repository is initialized with the current user’s ID, ensuring that all queries are bound to that identity. The index gsi_user_id_id uses user_id as the partition key and id as the sort key, which aligns with DynamoDB best practices for ownership-based access patterns. If your schema uses a different layout, adapt the key condition expression accordingly, but never omit the user constraint.

For writes, always include the user ID in the item and validate it on update or delete:

def update(id, attrs)
  # First ensure the item belongs to the user
  find(id) # raises if not found or unauthorized

  dynamodb.update_item(
    table_name: 'documents',
    key: { id: id, user_id: @user_id },
    update_expression: 'set #title = :title, content = :content',
    expression_attribute_names: { '#title' => 'title' },
    expression_attribute_values: {
      ':title' => attrs[:title],
      ':content' => attrs[:content]
    }
  )
end

By combining scoped queries with explicit ownership checks, Hanami applications can mitigate identification failures even when using a schemalayer like DynamoDB. Complementary practices include auditing access patterns in logs and periodically reviewing index designs to ensure user context is always present.