Auth Bypass in Sails with Dynamodb

Sails is a Node.js web framework that encourages convention-over-configuration and Waterline ORM-style adapters, including adapters for DynamoDB. Auth bypass in this stack occurs when access control is enforced at the framework or application layer but not consistently validated against the DynamoDB data store, or when adapter configuration inadvertently exposes unauthenticated endpoints. Because DynamoDB is a NoSQL store, permissions and data ownership checks must be explicit in application code; missing or incorrect checks can allow authenticated-user boundaries to be ignored.

One common pattern is using a DynamoDB adapter with global secondary indexes for user lookups. If queries rely only on indexes and do not enforce the requesting user’s identity as a key condition, an attacker can manipulate request parameters to access other users’ records. For example, an endpoint like /api/notes/:id might fetch a note by ID without verifying that the note’s userId matches the authenticated subject. With DynamoDB, a malformed query or a missing filter on the partition key can return data that should be invisible to the caller.

Another vector involves IAM policies attached to the DynamoDB credentials used by Sails. Overly permissive read/write permissions on a table used for user data can allow an authenticated but low-privilege context to perform actions beyond intended scope, such as scanning or updating items owned by other users. Misconfigured credential sets in development or CI can carry these permissions into production, amplifying the impact of an otherwise limited bypass.

Additionally, unauthenticated access to certain Sails routes that directly expose DynamoDB-backed models can bypass expected auth flows. If an endpoint is inadvertently left open or cached, and it performs getItem or query operations without verifying session or token state, an attacker can retrieve or modify data simply by guessing or enumerating identifiers. This is especially risky when combined with predictable key schemas, such as using timestamp-based IDs without ownership constraints.

These issues map to the broader Auth BOLA/IDOR category in middleBrick’s 12 security checks, which tests for unauthenticated and privilege-escalation paths. For the Sails + DynamoDB combination, the risk is elevated when authorization checks are inconsistent, relying on client-supplied identifiers without server-side re-verification against DynamoDB item ownership.

Remediation centers on enforcing ownership checks at the data-access layer and tightening IAM policies. In Sails, create a service that wraps DynamoDB operations and ensures every query includes the requesting user’s identifier as a partition or sort key condition. Avoid using raw IDs without scoping to the user context.

Example: a secure notes service in Sails using the AWS SDK for DynamoDB, with user ownership enforced:

// services/DynamoNoteService.js
const AWS = require('aws-sdk');
const dynamo = new AWS.DynamoDB.DocumentClient({ region: 'us-east-1' });

module.exports = {
  async getNoteForUser(noteId, userId) {
    const params = {
      TableName: process.env.NOTES_TABLE,
      Key: {
        userId: userId,        // partition key enforces ownership
        noteId: noteId         // sort key for the specific item
      }
    };
    const data = await dynamo.get(params).promise();
    return data.Item || null;
  },
  async listNotesForUser(userId, lastKey) {
    const params = {
      TableName: process.env.NOTES_TABLE,
      KeyConditionExpression: 'userId = :uid',
      ExpressionAttributeValues: { ':uid': userId },
      Limit: 20
    };
    if (lastKey) {
      params.ExclusiveStartKey = lastKey;
    }
    const data = await dynamo.query(params).promise();
    return data.Items;
  }
};

Use this service in your controllers instead of generic model finders:

// api/controllers/NoteController.js
module.exports = {
  async show(req, res) {
    const { id } = req.params;
    const user = req.user; // injected by your auth strategy
    if (!user || !user.id) {
      return res.unauthorized();
    }
    const note = await DynamoNoteService.getNoteForUser(id, user.id);
    if (!note) {
      return res.notFound();
    }
    return res.ok(note);
  }
};

For the DynamoDB table, ensure the IAM role used by Sails has scoped permissions. For example, attach a policy that restricts actions by the user’s partition key using condition keys:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/NotesTable",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/NotesTable/index/gsi-email",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
        }
      }
    }
  ]
}

Validate input rigorously and avoid exposing internal keys directly. Use explicit allowlists for attributes returned to the client. middleBrick’s Auth BOLA checks can help surface missing ownership constraints in your endpoints; the Pro plan’s continuous monitoring can detect regressions in DynamoDB query patterns over time, and the GitHub Action can fail builds if new routes lack scoped data access.