Information Disclosure in Chi with Dynamodb

Information disclosure in a Chi application that uses DynamoDB often stems from misconfigured access patterns and insufficient data ownership checks. When API endpoints expose DynamoDB table names or keys without proper authorization, an attacker can enumerate resources or infer sensitive data layouts. In Chi, routes that directly map to DynamoDB queries without validating the requesting user’s scope may return records that should remain private to other tenants or users.

For example, a Chi application might define a route like /users/:userId/profile and construct a DynamoDB query using the userId from the request path. If the handler does not verify that the authenticated subject matches userId, an attacker can modify the path parameter to access other users’ profiles, resulting in unauthorized information disclosure. This aligns with BOLA/IDOR checks in middleBrick’s 12 security tests, where improper ownership enforcement on DynamoDB-accessing endpoints is flagged.

DynamoDB’s low-level API can inadvertently expose sensitive attributes if responses are not carefully filtered. A Chi handler that retrieves an item with GetItem and returns the full DynamoDB JSON may include metadata such as aws:sdk:original-request fields or internal version attributes that should not reach the client. Additionally, error messages from the DynamoDB client—such as conditional check failures or provisioned throughput exceptions—can reveal table names or indexing strategies, aiding further reconnaissance.

Middleware in Chi that logs incoming requests and DynamoDB responses without redaction can also contribute to information leakage. Logs that include primary key values or attribute values might be retained in centralized logging systems accessible to unauthorized parties. middleBrick’s Data Exposure checks highlight such risks by correlating runtime behavior with OpenAPI specs, ensuring that documented responses do not exceed actual data exposure.

Another vector involves DynamoDB Streams and Lambda triggers integrated with Chi services. If a stream record is exposed through an endpoint or debug route, it may contain before/after images of modified items, disclosing change timelines and sensitive content. Proper authorization on any stream-consuming endpoint and strict output sanitization are essential to prevent inadvertent disclosure.

Using middleBrick’s CLI, you can scan a Chi + DynamoDB API to uncover these issues: middlebrick scan https://api.example.com. The report will detail findings such as missing attribute-level authorization on DynamoDB queries and overly verbose error messages, with remediation guidance mapped to OWASP API Top 10 and compliance frameworks.

Remediation focuses on enforcing ownership at the data access layer and sanitizing DynamoDB responses. In Chi, define a data access module that scopes queries by the authenticated subject’s unique identifier, ensuring that each DynamoDB operation includes a partition key condition derived from the current user’s ID.

Use parameterized queries and avoid string interpolation to prevent injection and accidental data exposure. For example, in a Chi handler, retrieve the subject ID from the session or JWT, then build a DynamoDB GetItem request that includes both the table name and a key condition that matches the subject’s partition key.

import Network.HTTP.Types (status403)
import Servant (throwError)
import qualified Data.Text as T
import Data.Aeson (object, (.=))
import Database.DynamoDB.Query (GetItem(..), Key(..), runResourceT)
import qualified Database.DynamoDB.Query as DDB

-- Chi handler that safely retrieves a user profile
getUserProfile :: T.Text -> ChiM (Either ServantErr UserProfile)
getUserProfile subjectId = do
    let key = Key
            { keyHash = subjectId
            , keyRange = Nothing
            }
    result &runResourceT &runDynamoDB $ do
        item &getItem ("UserProfiles" :: T.Text) key $ \response -
            case response of
                Left err -> throwError $ ServantErr status403 "Forbidden" (T.pack $ show err) []
                Right maybeItem -
                    case maybeItem of
                        Nothing -> throwError $ ServantErr status404 "Not Found" "Profile not found" []
                        Just item -> pure $ parseUserProfile item

This pattern ensures that the DynamoDB request is scoped to the authenticated subject, mitigating BOLA/IDOR risks identified by middleBrick. It also avoids returning the full DynamoDB metadata by transforming the item into a minimal domain type before serialization.

Sanitize responses by removing sensitive attributes before sending to the client. Define a function that strips internal fields and formats error messages generically.

import Data.Aeson (Value(Object), withObject, (.:), (.=))
import qualified Data.HashMap.Strict as HM

sanitizeItem :: Value -> Value
sanitizeItem (Object obj) = Object $ HM.filterWithKey keepField obj
  where
    keepField k _ = k /= "password" && k /= "apiKey" && k /= "internalVersion"
sanitizeItem v = v

For error handling, avoid exposing DynamoDB exception details. Catch low-level client errors and return generic messages while logging specifics internally for debugging.

import Control.Exception (try)
import qualified Network.AWS as AWS

safeGetItem :: T.Text -> Key -> ChiM (Either String Item)
safeGetItem table key = do
    res <- try $ runResourceT $ runDynamoDB $ getItem table key
    case res of
        Left (e :: AWS.SomeAWSException) -> do
            -- Log detailed error internally
            pure $ Left "Request failed"
        Right item -> pure $ Right item

middleBrick’s Pro plan supports continuous monitoring for such misconfigurations, scanning Chi endpoints on a schedule and alerting when insecure DynamoDB access patterns are detected. Its GitHub Action can gate CI/CD pipelines, failing builds if risk scores exceed defined thresholds.