Logging Monitoring Failures in Feathersjs with Dynamodb

When using Feathersjs with DynamoDB as the primary data store, insufficient logging and monitoring around data access and service errors can expose sensitive information, obscure misuse patterns, and delay detection of attacks such as unauthorized queries or injection attempts. Feathersjs services are event-driven and typically interact with databases through service hooks and custom code. If these interactions do not produce structured, contextual logs—especially key identifiers, input validation outcomes, and error details—operators lose visibility into anomalous behavior.

DynamoDB’s low-level API and query patterns can inadvertently expose risks when combined with incomplete logging in Feathersjs. For example, failing to log the full expression attribute names and values used in Scan or Query operations can make it difficult to detect BOLA/IDOR attempts where an attacker modifies record identifiers to access other users’ data. Similarly, generic error handling that swallows stack traces or DynamoDB conditional check failures means missed signals of privilege escalation or constraint bypass attacks. Without per-request correlation IDs and structured log output tied to the request lifecycle, it is hard to trace an individual API call through middleware, service hooks, and the DynamoDB layer, which impedes incident response and forensic analysis.

Another specific concern is the lack of fine-grained audit trails for data access. Feathersjs hooks may implement authorization at the service level, but if each hook does not emit structured logs containing the authenticated subject’s subject identifier, the record identifier accessed, the DynamoDB key condition expressions, and the outcome (allowed/denied), attackers can probe BOLA/IDOR and Property Authorization weaknesses without leaving detectable traces. In addition, missing monitoring of DynamoDB provisioned capacity errors (e.g., ProvisionedThroughputExceededException) can mask denial-of-service conditions or reconnaissance behavior that repeatedly triggers throttling to infer record existence.

To mitigate these risks, ensure Feathersjs services produce structured logs for every service method invocation, including hook execution results and DynamoDB client responses. Include fields such as timestamp, request ID, user context (if any), operation type (Get, Put, Update, Delete, Query, Scan), key schema details, condition expression outcomes, and sanitized error messages. Correlate these logs with runtime metrics like error rates, throttling events, and latency to detect anomalies such as unusual query rates on specific partition keys or repeated conditional check failures that may indicate probing for owned resources.

Apply structured logging in Feathersjs service hooks and handlers to capture DynamoDB interactions securely and with sufficient context. Below is a concrete example of a Feathersjs service hook that logs request metadata, input, and DynamoDB outcomes without exposing secrets or PII.

// src/hooks/audit-log.js
const { v4: uuidv4 } = require('uuid');

module.exports = function auditLog(options = {}) {
  return async context => {
    const requestId = uuidv4();
    const start = Date.now();

    // Attach request ID for correlation across services and logs
    context.meta.requestId = requestId;

    const { user } = context.params || {};
    const subjectId = user ? user.userId : 'anonymous';

    try {
      // Proceed with the original operation (e.g., DynamoDB query via a custom adapter)
      const result = await context.app.service(context.path)._superApply(context);

      // Log successful operation with key details
      console.info(JSON.stringify({
        level: 'info',
        timestamp: new Date().toISOString(),
        requestId,
        subjectId,
        path: context.path,
        method: context.method,
        operation: 'success',
        durationMs: Date.now() - start,
        // Avoid logging full record payloads to prevent accidental data exposure
        key: typeof result === 'object' && result !== null ? result.id || result._id : null
      }));

      return result;
    } catch (error) {
      // Log error details without exposing stack traces or internal fields
      console.warn(JSON.stringify({
        level: 'warn',
        timestamp: new Date().toISOString(),
        requestId,
        subjectId,
        path: context.path,
        method: context.method,
        operation: 'error',
        errorName: error.name,
        errorCode: error.code || null,
        // Map known DynamoDB errors to safe descriptors
        safeMessage: error.code === 'ConditionalCheckFailedException'
          ? 'Precondition not met for the item' 
          : error.message
      }));

      // Re-throw to preserve existing error handling in the service
      throw error;
    }
  };
};

Integrate this hook into your Feathersjs service to ensure every call produces auditable logs. For DynamoDB-specific interactions, also instrument the data access layer to log query expressions safely.

// src/services/records/records.class.js
const { DynamoDBClient, QueryCommand, ScanCommand } = require('@aws-sdk/client-dynamodb');
const { marshall, unmarshall } = require('@aws-sdk/util-dynamodb');

class RecordsService {
  constructor() {
    this.dynamo = new DynamoDBClient({ region: process.env.AWS_REGION });
    this.tableName = process.env.DYNAMODB_TABLE;
  }

  async find(params) {
    const { subjectId, // authenticated subject, e.g., from the subjectId in audit-log hook
      filters = {} } = params.query || {};

    const keyConditionExpression = subjectId
      ? 'userId = :uid'
      : 'attribute_exists(id)'; // defensive: avoid full scans in production

    const expressionAttributeValues = marshall({
      ':uid': subjectId,
      ...(filters.status ? { ':status': filters.status } : {})
    });

    const command = new QueryCommand({
      TableName: this.tableName,
      KeyConditionExpression: keyConditionExpression,
      ExpressionAttributeValues: expressionAttributeValues,
      Limit: filters.limit ? Number(filters.limit) : 10
    });

    // Log the command structure without leaking sensitive attribute values
    console.info(JSON.stringify({
      level: 'debug',
      name: 'dynamodb-operation',
      table: this.tableName,
      operation: 'Query',
      keyConditionExpression,
      hasFilters: Object.keys(filters).length > 0
    }));

    const response = await this.dynamo.send(command);

    // Log response metadata only
    console.info(JSON.stringify({
      level: 'debug',
      name: 'dynamodb-response',
      table: this.tableName,
      operation: 'Query',
      count: response.Count,
      scannedCount: response.ScannedCount,
      lastEvaluatedKey: !!response.LastEvaluatedKey
    }));

    return (response.Items || []).map(item => unmarshall(item));
  }
}

Ensure your monitoring captures DynamoDB error codes relevant to security and availability, such as ProvisionedThroughputExceededException, ResourceNotFoundException, and ConditionalCheckFailedException. Correlate these with request IDs from the audit log hook to identify patterns like repeated conditional failures on specific keys, which may indicate probing for owned resources or BOLA attempts.

Finally, validate and sanitize all user input before constructing DynamoDB expressions in Feathersjs services. Use parameterized expression attribute names and values, and avoid string concatenation to build queries. Combine runtime input validation hooks with the structured logging shown above to create defense-in-depth against injection and authorization bypass attempts.