Missing Authentication in Feathersjs with Dynamodb

Feathersjs is a framework for building JavaScript APIs with a service-oriented architecture. When a Feathersjs service that uses Dynamodb as the persistence layer does not enforce authentication, it can expose operations that should be restricted. The framework’s default configuration and common service templates make it easy to create endpoints, and if authentication middleware is omitted or misconfigured, callers can invoke methods without proving their identity.

With Dynamodb, requests are typically executed using the AWS SDK for JavaScript v3. If the service methods directly pass user-supplied parameters into DynamoDB operations such as GetItem, Scan, or Query, and no authorization checks are applied, attackers can interact with the table using unauthenticated AWS credentials supplied by the SDK (which may fall back to instance profiles or environment variables in some environments) or exploit misconfigured endpoints. A typical Feathersjs service file without authentication might look like this:

const { Service } = require('feathersjs');
const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb');

class TicketsService extends Service {
  async get(id, params) {
    const client = new DynamoDBClient({});
    const command = new GetItemCommand({
      TableName: 'Tickets',
      Key: { id: { S: id } }
    });
    const result = await client.send(command);
    return result.Item;
  }
}
module.exports = function() {
  const app = require('feathersjs')();
  app.use('/tickets', new TicketsService());
  return app;
};

In this example, there is no before hook that checks for authentication or authorization. An unauthenticated attacker can send a request to /tickets?id=123 and retrieve records they should not see, leading to information disclosure. This is a classic BOLA/IDOR pattern when the identifier is user-supplied and not scoped to the requesting user, but the root cause is missing authentication and lack of ownership validation.

The risk is compounded because Dynamodb responses may inadvertently reveal sensitive attributes if the table contains fields like email, token, or internal pointers. Without authentication, there is no identity to enforce row-level policies, and the service may default to returning data based only on the provided key. MiddleBrick’s scans detect such endpoints as unauthenticated LLM endpoints and flag findings related to Authentication and BOLA/IDOR checks, providing remediation guidance to enforce access controls before data exposure occurs.

To secure a Feathersjs service that uses Dynamodb, you must enforce authentication and scope queries to the authenticated subject. This involves adding before hooks that validate credentials and inject the requester identity into the query. Below is a secure version of the earlier example using an authentication hook and proper key scoping.

const { Service } = require('feathersjs');
const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb');
const { unauthenticated } = require('feathersjs-authentication-hooks');

class TicketsService extends Service {
  async get(id, params) {
    const client = new DynamoDBClient({});
    const command = new GetItemCommand({
      TableName: 'Tickets',
      Key: { id: { S: id } }
    });
    const result = await client.send(command);
    return result.Item;
  }
}

function hooks() {
  return {
    before: {
      all: [
        unauthenticated(),
        async context => {
          if (context.method === 'get' && context.id) {
            // Ensure the ticket belongs to the authenticated user
            if (context.params.user.sub !== context.id) {
              throw new Error('Unauthorized');
            }
          }
          return context;
        }
      ]
    }
  };
}

module.exports = function() {
  const app = require('feathersjs')();
  const service = new TicketsService();
  service.hooks(hooks());
  app.use('/tickets', service);
  return app;
};

In this remediation, unauthenticated() ensures that requests without valid credentials are rejected early. The second hook checks that the record key matches the authenticated subject’s identifier, implementing BOLA prevention. For broader queries, such as listing tickets, you should replace Scan with a Query on a Global Secondary Index keyed by user ID, ensuring that each request is scoped to a partition key that includes the user identifier. Here is an example of a secure query pattern:

async list(params) {
  const client = new DynamoDBClient({});
  const command = new QueryCommand({
    TableName: 'Tickets',
    IndexName: 'UserIndex',
    KeyConditionExpression: 'userId = :uid',
    ExpressionAttributeValues: {
      ':uid': { S: params.user.sub }
    }
  });
  const result = await client.send(command);
  return result.Items;
}

By combining service hooks with DynamoDB query patterns that enforce ownership via partition keys, you mitigate the risk of unauthenticated access and BOLA/IDOR. MiddleBrick’s scans will verify that authentication checks are present and that DynamoDB requests are properly constrained, reducing findings in the Authentication and Property Authorization categories.