Missing Tls in Feathersjs with Dynamodb

When a Feathersjs service uses the AWS SDK to communicate with DynamoDB without enforcing Transport Layer Security (TLS), client requests to the API endpoint can traverse networks where unencrypted traffic is observable or alterable. Feathersjs typically exposes HTTP endpoints; if those endpoints forward data to DynamoDB via an SDK client configured without explicit TLS requirements, the channel between the application runtime and DynamoDB may rely on default AWS SDK behavior. In some environments or configurations, this default can be insufficient to guarantee encrypted transit, particularly when custom HTTP agents or proxy configurations are in play.

The risk is amplified because Feathersjs services often handle authentication tokens, user profiles, and potentially sensitive business data. If a request to DynamoDB is transmitted without TLS, observers on the network (for example, in shared hosting or container overlay networks) could detect hostnames, metadata, or even extract unauthenticated tokens from responses. middleBrick scans this attack surface during an unauthenticated check, flagging scenarios where DynamoDB connections lack enforced TLS and noting the exposure of data-in-transit. This aligns with findings in categories such as Data Exposure and Encryption, where missing transport protections contribute to a lower security score.

Additionally, because Feathersjs can integrate with multiple data providers, developers might inadvertently configure the DynamoDB client with region-specific endpoints that do not mandate HTTPS. The unauthenticated attack surface tested by middleBrick includes these integration paths, ensuring that missing TLS is surfaced alongside other misconfigurations. Remediation focuses on explicit TLS enforcement in the SDK client and ensuring that all service-to-DynamoDB calls occur over HTTPS, which is reported with remediation guidance in the scan output.

To secure communication between Feathersjs and DynamoDB, explicitly configure the AWS SDK to use HTTPS and enforce TLS 1.2 or higher. Initialize the DynamoDB client with a custom HTTP agent that mandates TLS and avoid relying on environment variables that might permit insecure fallbacks. Below is a concrete example that shows how to create a secure DynamoDB client and integrate it into a Feathersjs service.

const { DynamoDB } = require('aws-sdk');
const https = require('https');

// Enforce TLS 1.2+ by providing a custom agent
const tlsAgent = new https.Agent({
  rejectUnauthorized: true,
  minVersion: 'TLSv1.2'
});

const dynamodb = new DynamoDB({
  region: process.env.AWS_REGION || 'us-east-1',
  httpOptions: {
    agent: tlsAgent,
    timeout: 5000
  },
  sslEnabled: true
});

// Example Feathersjs service using the secure client
const { Service } = require('feathersjs');
class DynamoDbItems {
  constructor(client) {
    this.client = client;
  }

  async find(params) {
    const { query } = params;
    const { TableName } = query;
    const paramsList = {
      TableName,
      Select: 'ALL_ATTRIBUTES'
    };
    const data = await this.client.scan(paramsList).promise();
    return data.Items || [];
  }

  async get(id, params) {
    const { TableName } = params.query;
    const paramsGet = {
      TableName,
      Key: {
        id: { S: id }
      }
    };
    const data = await this.client.get(paramsGet).promise();
    return data.Item || null;
  }
}

// Register the service with TLS-backed client
const app = require('feathers')();
app.use('/items', new DynamoDbItems(dynamodb));

This example ensures every request to DynamoDB uses a dedicated TLS agent and explicitly sets sslEnabled to true. It avoids default credential chains that might be permissive in development environments. middleBrick’s CLI can validate this configuration by scanning the endpoint and checking whether findings related to Encryption and Data Exposure are present; teams using the Pro plan can schedule continuous monitoring to detect regressions in TLS settings.

For teams leveraging the GitHub Action, adding a threshold for the security score ensures that builds fail if TLS enforcement is missing or if unauthenticated scan results show Encryption as a finding. The MCP Server allows developers to run on-demand checks from their IDE, providing immediate feedback when modifying DynamoDB integration code. By combining explicit TLS configuration with automated scanning, organizations reduce the risk of data-in-transit exposure while maintaining compatibility with compliance frameworks such as OWASP API Top 10 and PCI-DSS.