Zone Transfer in Feathersjs with Dynamodb

A Zone Transfer in the context of FeathersJS with DynamoDB typically refers to an authorization bypass where a service query exposes data that should be restricted by tenant, organization, or user scope. This occurs when the service definition does not enforce scoped access on query parameters, allowing an unauthenticated or low-privilege caller to retrieve records belonging to other zones or tenants. FeathersJS services are often configured with a ModelService that directly maps to a DynamoDB table. If the service hooks or query filters do not inject a scope condition (e.g., zoneId or tenantId) derived from the authenticated context, an attacker can manipulate the query to list or retrieve cross-zone records.

Consider a FeathersJS service defined as follows, where the DynamoDB table stores records tagged with a zoneId:

// src/services/records/records.class.js
const { Service } = require('feathers-sequelize');
const { DynamoDBDocumentClient, ScanCommand } = require('@aws-sdk/lib-dynamodb');
const { ddbDocClient } = require('../../lib/ddb-client');

class RecordsService extends Service {
  async find(params) {
    const { zoneId } = params.query;
    // Vulnerable: missing strict zoneId enforcement and filtering
    const command = new ScanCommand({
      TableName: process.env.DYNAMODB_TABLE,
    });
    const { Items } = await ddbDocClient.send(command);
    // If zoneId is provided but not used to filter, data from other zones may be returned
    return Items;
  }
}
module.exports = function (app) {
  app.use('/records', new RecordsService({ Model: app.get('sequelizeModel') }));
};

In this example, if params.query.zoneId is ignored and a full table scan is performed, an unauthenticated or low-privilege caller can enumerate all records across zones. DynamoDB itself does not enforce application-level scoping; it is the responsibility of the FeathersJS service to filter by the zone context. Without a hook that injects a filter like { zoneId: params.query.zoneId || userZoneId }, the service effectively exposes a Zone Transfer vector.

An authenticated attacker with a low-privilege role might leverage this by crafting a query that omits proper scoping, or by tampering with the query parameters. Since FeathersJS allows flexible query composition, if the service does not explicitly validate and enforce the scope, the DynamoDB scan or query will return data that should be isolated. This maps to OWASP API Top 10 Broken Object Level Authorization (BOLA) and can be detected by middleBrick as a BOLA/IDOR finding with severity high.

middleBrick’s LLM/AI Security checks are particularly useful here because prompt injection attempts can manipulate service behavior to exfiltrate cross-zone data. For example, an injected system prompt might coax the service to ignore zone filters. middleBrick scans can surface such risks by correlating spec definitions with runtime behavior, providing a finding that references compliance frameworks like PCI-DSS and SOC2 where zone-level data segregation is required.

Remediation centers on ensuring every DynamoDB operation in FeathersJS is scoped to the correct zone or tenant. This is achieved by modifying service hooks to inject filter expressions and by validating incoming query parameters against the authenticated user’s zone. Below is a secure implementation using the AWS SDK v3 for DynamoDB within a FeathersJS service.

// src/services/records/records.class.js
const { Service } = require('feathers-sequelize');
const { DynamoDBDocumentClient, ScanCommand } = require('@aws-sdk/lib-dynamodb');
const { ddbDocClient } = require('../../lib/ddb-client');

class RecordsService extends Service {
  async find(params) {
    const { zoneId } = params.query;
    // Enforce zone scoping: use authenticated user's zone if not provided
    const effectiveZoneId = zoneId || params.user.zoneId;
    if (!effectiveZoneId) {
      throw new Error('Zone ID is required');
    }
    const command = new ScanCommand({
      TableName: process.env.DYNAMODB_TABLE,
      FilterExpression: '#zone = :zone',
      ExpressionAttributeNames: { '#zone': 'zoneId' },
      ExpressionAttributeValues: { ':zone': effectiveZoneId },
    });
    const { Items } = await ddbDocClient.send(command);
    return Items;
  }
}
module.exports = function (app) {
  app.use('/records', new RecordsService({ Model: app.get('sequelizeModel') }));
};

Additionally, secure the service by adding a before hook that validates and enforces the zone context using the authenticated user’s claims. This prevents missing or tampered query parameters from bypassing scoping.

// src/services/records/hooks.js
const scopeByZone = context => {
  if (!context.params.user) {
    throw new Error('Unauthenticated');
  }
  // Ensure the query includes the user's zone if not explicitly set
  if (!context.params.query.zoneId) {
    context.params.query.zoneId = context.params.user.zoneId;
  }
  return context;
};
module.exports = {
  before: {
    all: [scopeByZone],
    find: [],
  },
};

For organizations using the Pro plan, continuous monitoring can be integrated via the GitHub Action to flag regressions where zone filters are missing from DynamoDB scan operations. The Action can fail builds if a scan detects a BOLA/IDOR pattern, ensuring that zone-level scoping is enforced before deployment.

When using the MCP Server to scan APIs from your IDE, developers receive immediate feedback that a DynamoDB-based FeathersJS service lacks proper zone scoping, enabling rapid remediation during development rather than post-deployment.