Broken Access Control in Spring Boot with Dynamodb

Broken Access Control occurs when authorization checks are missing or incorrectly enforced, allowing one user to access or modify another user's data. In a Spring Boot application using Amazon DynamoDB, this risk is amplified by a mismatch between application-layer logic and the permissions model of DynamoDB.

Spring Security can enforce method-level security with expressions like @PreAuthorize, but if the developer relies only on these checks without validating resource ownership in DynamoDB queries, an attacker can manipulate parameters (e.g., changing an ID in a URL) to access unauthorized items. DynamoDB does not enforce row-level ownership natively; it enforces permissions at the table or index level via IAM policies. If the application uses a shared IAM role for reads/writes and does not scope queries with the user identity, a BOLA/IDOR (Broken Level Authorization or Insecure Direct Object Reference) pattern emerges.

Consider an endpoint /users/{userId}/profile. If the service loads a profile by ID using a direct getItem call with a user-supplied userId but does not verify that the authenticated principal matches that userId, a user can iterate over arbitrary IDs. Because DynamoDB returns the item if the IAM role has dynamodb:GetItem permission, the application exposes other users' data without triggering an authorization failure at the database layer.

Insecure Direct Object Reference can also appear in scan or query operations. For example, a query that filters by a non-owner attribute (e.g., status = :status) without including the owner attribute (e.g., userId = :currentUserId) can return multiple records belonging to other users. DynamoDB’s conditional writes and filters are not a substitute for access control; they only validate data conditions, not permissions.

Another common pitfall is over-permissive IAM policies attached to the application role. Policies that allow dynamodb:Scan or broad dynamodb:Query on an entire table make it easier to exploit IDOR programmatically, as attackers can enumerate resources more efficiently. The principle of least privilege is especially important: scope IAM policies to specific partition keys and fine-grained operations, and enforce ownership checks in the application.

To detect such issues, middleBrick scans the unauthenticated and authenticated attack surface, checking whether authorization is missing or inconsistent across endpoints, and whether DynamoDB queries include identity-aware filters. It maps findings to OWASP API Top 10 (Broken Object Level Authorization) and provides remediation guidance tailored to Spring Boot and DynamoDB patterns.

Remediation centers on ensuring every DynamoDB operation includes the current user identity and that IAM policies follow least privilege. Below are concrete code examples using the AWS SDK for Java v2 with Spring Boot.

1. Enforce ownership in queries

Always include the authenticated user ID in the key condition expression or filter. Never rely on client-supplied IDs alone.

@Service
public class ProfileService {

    private final DynamoDbEnhancedClient dynamoDbEnhancedClient;

    public ProfileService(DynamoDbEnhancedClient dynamoDbEnhancedClient) {
        this.dynamoDbEnhancedClient = dynamoDbEnhancedClient;
    }

    public Profile getProfileForCurrentUser(String userId, String currentUserId) {
        if (!userId.equals(currentUserId)) {
            throw new AccessDeniedException("Unauthorized access to profile");
        }
        ProfileKey key = ProfileKey.builder()
                .userId(userId)
                .profileId(UUID.randomUUID().toString())
                .build();
        DynamoDbTable<ProfileKey, Profile> table = dynamoDbEnhancedClient.table("Profile", TableSchema.fromBean(Profile.class));
        return table.getItem(Key.builder().partitionValue(key).build());
    }
}

2. Use IAM conditions in policy evaluation

Leverage IAM condition operators to bind requests to the authenticated principal. In Spring Boot, this is typically enforced via the SDK’s use of credentials that contain policies with dynamodb:ResourceTag or dynamodb:LeadingKeys conditions. For example, an IAM policy can restrict dynamodb:GetItem to items where userId = ${cognito-identity.amazonaws.com:sub}. The SDK will sign requests with credentials tied to the caller, and DynamoDB evaluates the condition.

3. Parameterized queries with ownership filter

When querying, always include the owner attribute in the filter and avoid scanning entire tables.

public List<Order> listOrdersForCurrentUser(String currentUserId, String statusFilter) {
    DynamoDbTable<Order>> table = dynamoDbEnhancedClient.table("Orders", TableSchema.fromBean(Order.class));
    QueryConditional conditional = QueryConditional.keyEqualTo(Key.builder()
            .partitionValue(currentUserId)
            .sortValue(statusFilter)
            .build());
    Page<Order> page = table.query(r -> r.queryConditional(conditional));
    return page.items().stream().toList();
}

4. Least-privilege IAM policy example

Restrict operations to specific partition keys and avoid wildcards.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:region:account-id:table/Profile",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
        }
      }
    }
  ]
}

middleBrick’s Pro plan supports continuous monitoring and can alert when scans detect missing ownership checks or overly permissive IAM patterns in your API surface. Its GitHub Action can fail builds if risk scores drop below your defined threshold, and the MCP Server integrates into AI coding assistants to surface insecure DynamoDB usage in real time.