S3: BucketNotificationsHandler IAM Policy uses wildcard * by default

[tyagi-bhoopesh]

Describe the bug

When creating an S3 bucket using CDK’s Bucket construct, CDK automatically creates a Lambda (BucketNotificationsHandler) and attaches a default IAM policy:
{ "Action": "s3:PutBucketNotification", "Effect": "Allow", "Resource": "*" }
This policy uses a wildcard (*) for the Resource instead of restricting it to the specific bucket ARN.

The snippet code is here.
`
export class TestBucketExample extends Bucket {
constructor(stack: Stack) {
const bucketName = 'test-input';

    super(stack, 'TestBucketExample', {
        blockPublicAccess: BlockPublicAccess.BLOCK_ALL,
        encryption: BucketEncryption.S3_MANAGED,
        enforceSSL: true,
        bucketName,
        removalPolicy: RemovalPolicy.RETAIN,
        autoDeleteObjects: false,
        versioned: false,
        eventBridgeEnabled: true
    });
}

}
`

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Library Version

No response

Expected Behavior

The IAM policy should restrict the resource to only the bucket ARN instead of "*" for improved security.

Current Behavior

When you deploy the TestBucketExample construct:

CDK automatically creates a Lambda named something like BucketNotificationsHandler… to handle S3 notifications.

CDK attaches a default IAM policy to this Lambda:

{
"Action": "s3:PutBucketNotification",
"Effect": "Allow",
"Resource": "*"
}

The Resource is a wildcard *, meaning the Lambda could potentially modify notifications for any S3 bucket in the account.

This happens even though you are only using this Lambda for a specific bucket (test-input).

There is currently no CDK option to restrict this policy to the specific bucket ARN.

Reproduction Steps

Steps to reproduce the behavior:

1. Deploy the above CDK construct.
2. Check the generated CloudFormation template or IAM policies.
3. Observe the BucketNotificationsHandlerDefaultPolicy using "Resource": "".

Possible Solution

No response

Additional Information/Context

No response

AWS CDK Library version (aws-cdk-lib)

2.201.0

AWS CDK CLI version

2.1018.1

Node.js Version

22.16.0

OS

Windows 11

Language

TypeScript

Language Version

4.5.0

Other information

No response

[related-issues-bot-for-aws]

Hi @tyagi-bhoopesh,

Thanks for reporting! While a member of the CDK team reviews this, we've identified this as a potential duplicate.

Potential Duplicate Issues

• s3 bucket notifications creates IAM policy that has no resource boundary #5925: Both issues address the exact same security concern where the BucketNotificationsHandler Lambda is granted s3:PutBucketNotification permission with "Resource": "*", allowing it to potentially modify notifications for any S3 bucket in the account. Both request the same solution - scoping down the IAM policy to specific bucket ARNs for improved security.

This message was generated automatically to help connect related conversations and improve discoverability.

Please react with 👍 or 👎 to let us know if this response was helpful!

Thank you for helping improve CDK! 🙌

Related Issues

• [s3] BucketNotifications should take an IRole #9918
• (aws-s3): supply custom role when adding bucket notifications #13241
• aws-s3/notifications-resource: Scope down S3 bucket notifications lambda permission to only buckets it interacts with #27234

[pahud]

Hi @tyagi-bhoopesh,

Thank you for reporting this security concern. This is indeed a valid issue where the BucketNotificationsHandler Lambda function receives overly broad IAM permissions.

This appears to be a duplicate of issue #5925, which has been tracking the same security concern since January 2020. The root cause is in the NotificationsResourceHandler where the IAM policy is hard-coded with resources: ['*'] instead of being scoped to specific bucket ARNs.

The current implementation uses a stack singleton pattern for the notifications handler, which creates the IAM policy before knowing which specific buckets it will manage. While this ensures functionality across all buckets in a stack, it violates the principle of least privilege by granting s3:PutBucketNotification permissions on all S3 buckets in the account.

Potential solutions include:

1. Adding bucket-specific permissions dynamically as buckets are registered
2. Creating a configuration option to allow scoped policies
3. Collecting all bucket ARNs at synthesis time and creating a properly scoped policy

Based on my analysis of the issue, here is the option we should consider:

Dynamic Resource Collection

Approach: Modify the NotificationsResourceHandler to collect bucket ARNs during synthesis and create a scoped policy.

Implementation:

// In NotificationsResourceHandler
private bucketArns: string[] = [];

public addBucket(bucketArn: string) {
  if (!this.bucketArns.includes(bucketArn)) {
    this.bucketArns.push(bucketArn);
    // Update the policy with the new bucket ARN
    this.role.addToPrincipalPolicy(new iam.PolicyStatement({
      actions: ['s3:PutBucketNotification'],
      resources: [bucketArn],
    }));
  }
}

Pros:
• Maintains backward compatibility
• Follows principle of least privilege
• No breaking changes to user code
• Automatically scopes to only buckets that actually need notifications

Cons:
• Requires coordination between bucket creation and handler registration
• Slightly more complex implementation

However, with the current singleton pattern and my proposed implementation, there's a race condition and policy duplication issue:

// Stack with multiple buckets
const bucket1 = new Bucket(stack, 'Bucket1', { eventBridgeEnabled: true });
const bucket2 = new Bucket(stack, 'Bucket2', { eventBridgeEnabled: true });
const bucket3 = new Bucket(stack, 'Bucket3', { eventBridgeEnabled: true });

Issues with my initial approach:

1. Multiple Policy Statements: Each addBucket() call creates a separate policy statement
2. IAM Policy Limits: AWS has limits on policy size and number of statements
3. Inefficient: Creates redundant policy statements instead of one consolidated statement

A better Implementation would be Deferred Policy Creation or even better approach - collect all buckets at the stack level.

I'll submit an immediate PR for this and bring this up to the team for review.