rules-dynamodb

RISK: DeleteItem without a ConditionExpression can silently delete an item that has been modified by a concurrent writer — lost-update and TOCTOU vulnerability. FIX: Add a ConditionExpression (e.g. 'attribute_exists(pk)' or a version/etag check) to make the delete conditional and safe under concurrency.

RISK: Building a DynamoDB FilterExpression or KeyConditionExpression by string concatenation or interpolation can allow injection of malicious expression syntax, bypassing intended data access controls. FIX: Always use ExpressionAttributeValues with named placeholders (:val) — never interpolate user input directly into expression strings.

DynamoDB Scan reads every item in the table, consuming full provisioned read capacity and incurring cost proportional to table size. For production workloads, prefer Query with a known partition key, or a GSI. If Scan is intentional (e.g. data migration), add a FilterExpression to reduce data transfer.

RISK: Hardcoded AWS credentials grant full DynamoDB (and potentially account-wide) access — exposure via VCS history is a critical secret leak that has caused major data breaches. FIX: Use IAM roles (EC2/ECS/Lambda instance profiles), AWS SSO, or read from environment variables via the AWS SDK credential chain. Revoke the exposed key immediately via IAM.

RISK: DynamoDB tables without SSESpecification use default AWS-managed encryption at rest. For sensitive data, explicitly configure CMK (KMS) encryption to retain control over key rotation and access. FIX: Set SSESpecification: { Enabled: true, SSEType: 'KMS', KMSMasterKeyId: '<key-id>' }.