AWS SQS Queue Missing Server-Side Encryption

High Risk Infrastructure Security
awssqsencryptiondata-at-restkmsmessage-queuecomplianceterraformcloudformation

What it is

A critical security vulnerability where Amazon SQS queues are configured without server-side encryption, leaving sensitive message data unprotected at rest. This exposes message contents, metadata, and potentially sensitive application data to unauthorized access if AWS storage systems are compromised or accessed improperly. SQS messages may contain authentication tokens, personal information, financial data, or business-critical information that requires encryption protection.

# VULNERABLE: SQS queue without encryption
resource "aws_sqs_queue" "user_notifications" {
  name                      = "user-notifications-queue"
  delay_seconds             = 90
  max_message_size          = 2048
  message_retention_seconds = 86400
  visibility_timeout_seconds = 300
  
  # Missing: No encryption configuration
  # Messages stored in plaintext
  
  tags = {
    Environment = "production"
    Application = "user-service"
  }
}

# VULNERABLE: CloudFormation without encryption
Resources:
  UserNotificationQueue:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: user-notifications-queue
      DelaySeconds: 90
      MaxMessageSize: 2048
      MessageRetentionPeriod: 86400
      VisibilityTimeout: 300
      # Missing: KmsMasterKeyId property
      Tags:
        - Key: Environment
          Value: production
        - Key: Application
          Value: user-service

# VULNERABLE: AWS CLI queue creation
aws sqs create-queue \
  --queue-name user-notifications-queue \
  --attributes DelaySeconds=90,MaxMessageSize=2048 \
  # Missing: No encryption attributes specified
# SECURE: SQS queue with KMS encryption (AWS managed key)
resource "aws_sqs_queue" "user_notifications" {
  name                      = "user-notifications-queue"
  delay_seconds             = 90
  max_message_size          = 2048
  message_retention_seconds = 86400
  visibility_timeout_seconds = 300
  
  # Enable server-side encryption with AWS managed key
  kms_master_key_id = "alias/aws/sqs"
  
  tags = {
    Environment = "production"
    Application = "user-service"
  }
}

# SECURE: CloudFormation with encryption
Resources:
  UserNotificationQueue:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: user-notifications-queue
      DelaySeconds: 90
      MaxMessageSize: 2048
      MessageRetentionPeriod: 86400
      VisibilityTimeout: 300
      KmsMasterKeyId: alias/aws/sqs
      Tags:
        - Key: Environment
          Value: production
        - Key: Application
          Value: user-service

# SECURE: AWS CLI with encryption
aws sqs create-queue \
  --queue-name user-notifications-queue \
  --attributes '{
    "DelaySeconds": "90",
    "MaxMessageSize": "2048",
    "KmsMasterKeyId": "alias/aws/sqs"
  }'

💡 Why This Fix Works

The vulnerable examples show SQS queues created without encryption configuration, leaving message data stored in plaintext. The secure alternatives demonstrate proper KMS encryption setup with both customer-managed and AWS-managed keys, including appropriate key policies and access controls.

Why it happens

Developers create SQS queues without configuring server-side encryption, leaving messages stored in plaintext. This commonly occurs when prioritizing quick deployment over security, or when team members are unaware of encryption requirements. The default SQS configuration does not enable encryption, requiring explicit configuration of KMS keys and encryption settings.

Root causes

SQS Queue Without KMS Encryption Configuration

Developers create SQS queues without configuring server-side encryption, leaving messages stored in plaintext. This commonly occurs when prioritizing quick deployment over security, or when team members are unaware of encryption requirements. The default SQS configuration does not enable encryption, requiring explicit configuration of KMS keys and encryption settings.

Missing KMS Key Configuration in Infrastructure Code

Infrastructure as Code templates (Terraform, CloudFormation) that define SQS queues without specifying the kms_master_key_id or KmsMasterKeyId properties. This results in queues being created without encryption, even when encryption policies exist at the organizational level. Often occurs when using basic examples or starter templates that don't include security best practices.

Fixes

1

Enable KMS Encryption for SQS Queue

Configure server-side encryption using AWS KMS keys. Set kms_master_key_id in Terraform or KmsMasterKeyId in CloudFormation to enable encryption at rest. Use AWS managed keys (alias/aws/sqs) for simplicity or customer-managed keys for additional control and compliance requirements.

2

Implement Queue Encryption Policy

Create organizational policies that require SQS encryption across all environments. Use AWS Config rules, Service Control Policies (SCPs), or infrastructure scanning tools to automatically detect and prevent unencrypted queue creation. Establish security review processes for queue configurations.

3

Configure Key Rotation and Access Controls

When using customer-managed KMS keys, enable automatic key rotation and configure appropriate key policies. Ensure that only necessary services and roles have access to decrypt SQS messages. Implement least-privilege access patterns for both queue operations and KMS key usage.

Detect This Vulnerability in Your Code

Sourcery automatically identifies aws sqs queue missing server-side encryption and many other security issues in your codebase.

Scan Your Code for Free Explore More Vulnerabilities