Nosql Injection in Fiber with Dynamodb

NoSQL injection in a Fiber application that uses DynamoDB typically occurs when user-controlled input is concatenated into query parameters, key conditions, or expression attribute values without proper validation or parameterization. Because DynamoDB’s low-level API often builds requests from maps and strings, constructing queries by directly interpolating request values can introduce injection-like behavior.

In a Fiber route, developers might build a DynamoDB input map using values from query strings or headers. For example, using a path parameter to construct a KeyConditionExpression without sanitization allows an attacker to change the logical structure of the expression. A crafted payload can extend the query scope or bypass intended partition key filters. The DynamoDB API itself does not fail with a syntax error for unexpected operators; instead, it may return unintended items or an empty result set, which can be interpreted differently by the application layer.

Consider a scenario where the partition key and sort key are derived from user input. An attacker can supply values such as id with value#1 and sort with attr > '' OR begins_with(attr, '') when the query is assembled via string concatenation. If the application builds the KeyConditionExpression as partitionKey = :pk AND sortKey > :sk using raw strings, the injection-like payload can alter the logical intent, potentially exposing other items or causing a full table scan depending on how the condition is interpreted.

Another vector involves expression attribute names and values. If an application dynamically injects attribute names into UpdateItem or PutItem requests based on user input, an attacker might provide attribute names that reference nested data or metadata fields. While DynamoDB does not support traditional SQL-style injection, malformed or unexpected input can change the semantics of ConditionExpressions or UpdateExpressions. For example, supplying an attribute name like attributeNames.#status and values that modify the expression can bypass intended checks, leading to unauthorized updates or data exposure.

Because NoSQL injection changes query semantics rather than breaking syntax, the impact can be subtle: information disclosure, privilege escalation via modified authorization checks, or data corruption. In a Fiber service, these issues are amplified when request binding is implicit and developers assume the database layer will enforce strict filtering. MiddleBrick scans detect such patterns by correlating endpoint inputs with DynamoDB request construction and flagging unparameterized expression building as a high-risk finding.

Remediation centers on strict input validation, using DynamoDB’s native parameterization for expression attribute names and values, and avoiding string concatenation for query construction. In Fiber, ensure route parameters and query values are validated against a schema before they are used to build DynamoDB input structures.

Use the AWS SDK’s built-in mechanisms. For KeyConditionExpression, supply partition key values directly as attribute values rather than embedding them in strings. For expression attributes, always provide two maps: one for attribute names (placeholders) and one for attribute values. This prevents injection-like manipulation of logical operators or key conditions.

Example 1: Safe query with expression attribute names and values in Fiber.

// Correct: parameterize expression attribute names and values
const params = {
  TableName: 'Items',
  KeyConditionExpression: '#pk = :pk AND #sk > :sk',
  ExpressionAttributeNames: {
    '#pk': 'partitionKey',
    '#sk': 'sortKey'
  },
  ExpressionAttributeValues: {
    ':pk': { S: 'item123' },
    ':sk': { N: '10' }
  }
};
const command = new QueryCommand(params);
const response = await dynamoClient.send(command);

Example 2: Safe update with expression attribute names and validation in Fiber.

// Validate input first, then use placeholders
const schema = Joi.object({
  partitionKey: Joi.string().required(),
  sortKey: Joi.number().required(),
  newValue: Joi.string().required()
});
const { error, value } = schema.validate({ 
  partitionKey: req.params.id, 
  sortKey: Number(req.query.sort), 
  newValue: req.body.value 
});
if (error) { res.status(400).send(error.details); return; }

const updateParams = {
  TableName: 'Items',
  Key: { partitionKey: { S: value.partitionKey }, sortKey: { N: value.sortKey.toString() } },
  UpdateExpression: 'SET #attr = :val',
  ConditionExpression: '#attr <> :val',
  ExpressionAttributeNames: { '#attr': 'attributeName' },
  ExpressionAttributeValues: { ':val': { S: value.newValue } }
};
const updateCmd = new UpdateItemCommand(updateParams);
await dynamoClient.send(updateCmd);

Example 3: Avoid building expressions by concatenation. Do not do this:

// Risky: concatenating user input into KeyConditionExpression
const keyCondition = `partitionKey = '${req.params.id}' AND sortKey > ${req.query.sort}`;
const params = {
  TableName: 'Items',
  KeyConditionExpression: keyCondition
};

Instead, always rely on the SDK’s structure and validate inputs centrally. MiddleBrick’s scans highlight endpoints where expression building appears dynamic, and the Pro plan can schedule continuous monitoring to catch regressions as endpoints evolve.