Null Pointer Dereference in Fiber with Dynamodb

A null pointer dereference in a Fiber application that interacts with DynamoDB typically occurs when the application attempts to access properties or invoke methods on an object that is null or undefined. This can happen when DynamoDB responses are not defensively checked before use, especially when working with the DocumentClient or when mapping low-level responses to domain models.

Consider a typical handler in Fiber that retrieves an item by ID:

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

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

app.get("/user/:id", async (req, res) => {
  const params = {
    TableName: process.env.USERS_TABLE,
    Key: marshall({ userId: req.params.id })
  };
  const command = new GetItemCommand(params);
  const result = await client.send(command);

  // Risk: if result.Item is undefined, unmarshall returns undefined
  const user = unmarshall(result.Item);
  res.send(user.name); // Potential null pointer dereference if user is undefined
});

If the item does not exist, result.Item is undefined, and unmarshall returns undefined. Accessing user.name then throws a null pointer dereference. This pattern is common across CRUD endpoints and can be exposed by unauthenticated scans that probe for missing existence checks.

Another scenario involves optional attributes in DynamoDB documents. If your schema allows missing fields and your code assumes their presence, runtime errors occur:

app.get("/order/:orderId", async (req, res) => {
  const params = {
    TableName: process.env.ORDERS_TABLE,
    Key: marshall({ orderId: req.params.orderId })
  };
  const result = await client.send(new GetItemCommand(params));
  const order = unmarshall(result.Item);

  // Risk: order.payment may be undefined if not stored
  const amount = order.payment.amount;
  res.json({ total: amount });
});

Here, order.payment might be absent, leading to a null pointer dereference at order.payment.amount. In security scans, such unchecked optional fields are flagged as potential null pointer dereferences, especially when combined with mass assignment or missing validation.

In the context of API security scanning, these patterns are detectable because they represent an unauthenticated attack surface where missing data leads to runtime exceptions. The scanner does not fix the code but highlights the need for validation and existence checks to prevent unexpected crashes.

Remediation focuses on validating the presence of objects before accessing properties and ensuring that DynamoDB responses are handled consistently. Use optional chaining and explicit checks to avoid null pointer dereferences.

1. Validate existence before access

app.get("/user/:id", async (req, res) => {
  const params = {
    TableName: process.env.USERS_TABLE,
    Key: marshall({ userId: req.params.id })
  };
  const result = await client.send(new GetItemCommand(params));

  if (!result.Item) {
    return res.status(404).send({ error: "User not found" });
  }

  const user = unmarshall(result.Item);
  res.send({ name: user.name });
});

This pattern ensures that result.Item is confirmed present before unmarshall is called, eliminating the null pointer risk.

2. Guard optional nested fields

app.get("/order/:orderId", async (req, res) => {
  const params = {
    TableName: process.env.ORDERS_TABLE,
    Key: marshall({ orderId: req.params.orderId })
  };
  const result = await client.send(new GetItemCommand(params));
  const order = unmarshall(result.Item);

  if (!order || !order.payment) {
    return res.status(400).send({ error: "Payment information missing" });
  }

  const amount = order.payment.amount;
  res.json({ total: amount });
});

By checking both order and order.payment, the code avoids dereferencing undefined. This is particularly important for DynamoDB tables where attributes may be omitted.

3. Use helper functions for safe access

function getNested(obj, ...keys) {
  return keys.reduce((acc, key) => (acc && acc[key] !== undefined) ? acc[key] : null, obj);
}

app.get("/profile/:userId", async (req, res) => {
  const params = {
    TableName: process.env.PROFILES_TABLE,
    Key: marshall({ userId: req.params.userId })
  };
  const result = await client.send(new GetItemCommand(params));
  const profile = unmarshall(result.Item);

  const address = getNested(profile, "address", "city");
  if (address === null) {
    return res.status(400).send({ error: "Address data incomplete" });
  }
  res.send({ city: address });
});

This approach encapsulates safe traversal logic and makes it reusable across endpoints, reducing repetitive null checks.

middleBrick scans can identify these patterns by analyzing unauthenticated endpoints and flagging locations where DynamoDB responses are used without validation. While the tool does not automatically apply fixes, its findings include remediation guidance that aligns with the code patterns shown above.

For teams managing multiple services, the Pro plan includes continuous monitoring so that new endpoints or changes to DynamoDB response shapes are flagged early, and the GitHub Action can fail builds if risk scores exceed configured thresholds. The MCP Server allows you to run scans directly from development environments, integrating checks into your workflow without leaving your editor.