How to avoid S3 data leaks?

Andreas Wittig – 15 Oct 2019

You can also listen to this topic in our podcast!

Not a week goes by without a frightening announcement that an organization has leaked confidential data from Amazon S3 accidentally. Most often, the root cause of a security breach is a misconfiguration of S3 access control.

3 rules to avoid data leaking from S3

It may not have been AWS’s best decision to provide a service that allows you to both make data publicly available and store highly sensitive data. But it is what it is. Therefore, you should be very careful when configuring access control for your S3 buckets. The following rules make sure you do not make data available publicly.

Rule #1: Use IAM policies to grant access to your S3 bucket

Unfortunately, there are three different ways to control access to an S3 bucket. Use the following steps to decide which option to choose:

  1. Use an IAM policy to grant access to your S3 bucket whenever the caller can authenticate as an IAM principal (user or role).
  2. Use a bucket policy only in exceptional cases when using an IAM policy is not an option (e.g., to allow read access from the whole organization, …).
  3. Never use bucket or object ACLs.

Believe me, when doing security reviews, I’ve seen too many misconfigured bucket policies and ACLs. Sticking to IAM policies simplifies access control a lot.

Rule #2: Enable Block Public Access

AWS announced Block Public Access in November 2018, a safety net to protect the data stored in your S3 buckets. There are four options available:

  • Block public access to buckets and objects granted through new access control lists (ACLs)
  • Block public access to buckets and objects granted through any access control lists (ACLs)
  • Block public access to buckets and objects granted through new public bucket policies
  • Block public and cross-account access to buckets and objects through any public bucket policies

Do none of your S3 buckets contain data that you want to share publicly? Lucky you!

Enable Block Public Access for all S3 buckets in your AWS account:

  1. Open the AWS Management Console.
  2. Go to the S3 service.
  3. Select Block public access (account settings) from the sub-navigation.
  4. Enable Block all public access.
  5. Sleep well. 🛌

Enable Block Public Access for all S3 buckets in your AWS account

Alternatively, you can use the Terraform resource aws_s3_account_public_access_block to roll-out the configuration to your AWS accounts. Unfortunately, CloudFormation does still not allow you to do so. 😡

resource "aws_s3_account_public_access_block" "example" {
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true

But what to do when you use S3 for both use cases: public and confidential data? In that scenario, you need to enable Block Public Access only for S3 buckets containing sensitive data.

cloudonaut plus

Staying ahead of the game with Amazon Web Services (AWS) is a challenge. Our weekly videos and online events provide independent insights into the world of cloud. Subscribe to cloudonaut plus to get access to our exclusive videos and online events.

Subscribe now!

By default, AWS enables all four options when you create a new S3 bucket via the AWS Management Console. However, you need to enable Block Public Access yourself when working with Terraform or CloudFormation.

Use the aws_s3_bucket_public_access_block resource when working with Terraform.

resource "aws_s3_bucket" "example" {
bucket = "example"

resource "aws_s3_bucket_public_access_block" "example" {
bucket = "${}"

block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true

Alternatively, use the PublicAccessBlockConfiguration property of the AWS::S3::Bucket resource when working with CloudFormation.

Type: 'AWS::S3::Bucket'
BucketName: 'example'
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true

Don’t forget to enable Block Public Access for all existing and future buckets containing private data.

Rule #3: Separate public from private data

Do not mix public data and private data into the same S3 bucket. Doing so increases the risk of a misconfiguration dramatically. Also, make sure the name of your S3 bucket indicates whether it contains private or public data.

Rule #4: Monitor Trusted Advisor findings

I highly recommend asking a 3rd party to review your access control configuration regularly. You might want to task a professional to do so (hint: we are offering technical security reviews of IAM (including S3) and VPC networking). Another option is to ask the AWS Trusted Advisor for help.

The Trusted Advisor constantly scans your AWS account for typical weak points, not only of your security configuration, in an automated way. One of the many checks performed by the Trusted Advisor is called Amazon S3 Bucket Permissions which watches for public access granted by bucket policies or ACLs.

Trusted Advisor: Amazon S3 Bucket Permissions check

I highly recommend enabling Weekly Email Notification from the Trusted Advisor. That way, you’ll prevent missing a warning.

  1. Open the AWS Management Console.
  2. Go to the Trusted Advisor service.
  3. Select Preferences from the sub-navigation.
  4. Enable weekly email notifications.
  5. Sleep a little bit better. 🛌


Take your time configuring the access permissions for your S3 bucket. Follow these three rules to avoid leaking data from S3:

  1. Use IAM policies to control access to your data stored in S3. Avoid using bucket policies whenever possible. Do not even think about using a bucket or object ACLs.
  2. Enable Block Public Access. If possible, do so for your AWS account to protect all buckets. If not, make sure to enable Block Public Access for all existing and future S3 buckets containing private data.
  3. Do not mix private and public data within an S3 bucket. Also make sure, the bucket name includes the data classification.
  4. Enable email notifications from Trusted Advisor to get notified of unintended changes to your bucket policies and bucket ACLs. Especially, watch out for the Amazon S3 Bucket Permissions check.

Are 3rd parties uploading data to your S3 bucket? Check for malware with our S3 Virus Scan solution. Available on the AWS Marketplace S3 Virus Scan and on GitHub widdix/aws-s3-virusscan.

Tags: aws security s3
Andreas Wittig

Andreas Wittig

I'm an independent consultant, technical writer, and programming founder. All these activities have to do with AWS. I'm writing this blog and all other projects together with my brother Michael.

In 2009, we joined the same company as software developers. Three years later, we were looking for a way to deploy our software—an online banking platform—in an agile way. We got excited about the possibilities in the cloud and the DevOps movement. It’s no wonder we ended up migrating the whole infrastructure of Tullius Walden Bank to AWS. This was a first in the finance industry, at least in Germany! Since 2015, we have accelerated the cloud journeys of startups, mid-sized companies, and enterprises. We have penned books like Amazon Web Services in Action and Rapid Docker on AWS, we regularly update our blog, and we are contributing to the Open Source community. Besides running a 2-headed consultancy, we are entrepreneurs building Software-as-a-Service products.

We are available for projects.

You can contact me via Email, Twitter, and LinkedIn.

Briefcase icon
Hire me