Integer Overflow in Fiber with Dynamodb

An integer overflow in a Fiber application that uses DynamoDB can arise when user-supplied numeric values are used to compute limits, offsets, or buffer sizes before issuing DynamoDB operations. In JavaScript, numbers are IEEE 754 double-precision floating-point values, which can safely represent integers only up to Number.MAX_SAFE_INTEGER (2^53 - 1). If a value exceeds this, precision is lost and arithmetic can produce unexpected results, such as wrapping to zero or negative numbers when used in bitwise operations or when converted to 32-bit integers for pagination or partitioning logic.

When such a computed value is used to control DynamoDB request parameters—such as Limit, ExclusiveStartKey numeric attributes, or partition key-derived numeric segments—an overflow can cause the request to read unintended data ranges, skip segments, or generate requests with invalid parameters that expose internal behavior. For example, an overflow that turns a large expected limit into a small number can result in incomplete scans that leak data or create patterns observable via timing or response structure, contributing to information exposure as part of the broader BOLA/IDOR and Data Exposure checks that middleBrick tests in parallel.

In a black-box scan, middleBrick runs checks in parallel including Input Validation and Data Exposure, which can detect anomalies in how numeric inputs affect DynamoDB responses. If an API endpoint accepts a numeric parameter like batchSize or offset, passes it to DynamoDB without proper range validation, and returns differing response sizes or structures based on overflow-induced values, the scan can surface inconsistent behavior, missing auth on sensitive paths, or data exposure tied to malformed requests.

Consider an endpoint that computes a DynamoDB query limit from a user value: if the value is not clamped to safe integer ranges before use, an overflow can reduce the limit unexpectedly, causing the server to paginate incorrectly and potentially return more items than intended across multiple requests. This intersects with BOLA/IDOR when different accounts receive different effective limits due to overflow, enabling one user to infer or access another’s data slice. By correlating multiple scan findings—Input Validation, Data Exposure, and BOLA/IDOR—middleBrick highlights how integer handling interacts with DynamoDB usage to create risky observable behaviors.

Remediation centers on validating and sanitizing all numeric inputs before using them in DynamoDB operations, ensuring values remain within safe integer ranges and are not used to compute offsets or limits that affect pagination or partitioning logic.

Example: validating a batch size parameter before using it in a DynamoDB query in a Fiber handler.

const { DynamoDBClient, QueryCommand } = require("@aws-sdk/client-dynamodb");
const { unmarshall } = require("@aws-sdk/util-dynamodb");

const client = new DynamoDBClient({ region: "us-east-1" });

function isSafeInteger(value) {
  return Number.isInteger(value) && value >= 0 && value <= Number.MAX_SAFE_INTEGER;
}

app.get("/items", async (req, res) => {
  const batchSize = Number(req.query.batchSize) || 10;

  if (!isSafeInteger(batchSize) || batchSize > 1000) {
    return res.status(400).json({ error: "Invalid batchSize" });
  }

  const params = {
    TableName: process.env.DYNAMO_TABLE,
    Limit: batchSize,
  };

  try {
    const data = await client.send(new QueryCommand(params));
    const items = data.Items.map(unmarshall);
    res.json({ items, lastKey: data.LastEvaluatedKey });
  } catch (err) {
    res.status(500).json({ error: "DynamoDB error" });
  }
});

Example: safely handling an offset that must be derived from a numeric attribute stored in DynamoDB, avoiding overflow when reconstructing pagination state.

function parseOffset(queryOffset) {
  const offset = Number(queryOffset);
  if (!Number.isFinite(offset) || offset < 0 || offset > Number.MAX_SAFE_INTEGER) {
    throw new Error("Invalid offset");
  }
  return offset;
}

app.get("/records", async (req, res) => {
  const offset = parseOffset(req.query.offset);
  // Use offset for application-level pagination, not as a direct DynamoDB Limit
  // Fetch a safe page size and skip items in memory for small offsets, or use a cursor-based approach.
  const pageSize = 50;
  const params = {
    TableName: process.env.DYNAMO_TABLE,
    Limit: pageSize + 1, // one extra to detect more pages
  };
  const data = await client.send(new QueryCommand(params));
  const items = data.Items.map(unmarshall);
  const hasMore = items.length > pageSize;
  const safeItems = hasMore ? items.slice(0, pageSize) : items;
  res.json({ items: safeItems, nextCursor: hasMore ? items[pageSize].id : null });
});

General guidance: always treat numeric inputs as untrusted, enforce min/max bounds, prefer cursor-based pagination over large numeric offsets, and avoid computing sizes or indexes via arithmetic on raw user input. By combining these practices with the checks middleBrick runs—such as Input Validation, Data Exposure, and BOLA/IDOR—you reduce the risk that integer overflow influences DynamoDB behavior in observable ways.