Common Aws S3 Misconfigurations And How To Avoid Them

Tom Bushmitz

Common Aws S3 Misconfigurations And How To Avoid Them

Tom Bushmitz


Share on linkedin
Share on facebook
Share on twitter

AWS’s simple storage service also known as S3 is the most popular public cloud service and currently continues to hold the largest market share within the cloud services market.

AWS S3 storage is used both by small and large businesses alike and the number of buckets used vary greatly from just a few to thousands of buckets. Some of which are used for external purposes and should be configured as public and unencrypted. Others are meant for internal use only but often are left expos ed to the internet unintentionally.

There is no shortage of news headlines relating to data leakages and breaches resulting from misconfigured S3 buckets which were left exposed. 

When a new Bucket is created it is “Private” by default. Nevertheless, lots of private buckets end up exposed. The exposures are typically  the result of a human error in the access management setting processes.

AWS offers 3 mechanisms for configuring and managing access and this is where the trouble may begin.

  1. Identity and Access Management (IAM) policies for creating and managing multiple users under a single AWS account. 
  2. Bucket policies which allows you to define various rules which apply across all requests to S3 resources.
  3. Access Control Lists (ACLs) – this type of settings allows you to grant specific permissions like  READ, WRITE, FULL_CONTROL to specific users or groups for an individual bucket or object. 

On top of these options, admins can also create a “PreSigned URL”, through a generated URL, users can be granted temporary write or read access to a bucket or objects

Each of these options presents a potential for misconfiguration and as if this wasn’t enough, there is also the challenge of understanding how all these mechanisms work together. For example, users can block the Access Control List for a specific bucket, but if the bucket’s policy is misconfigured, then the data will still be completely exposed  to the Internet.

Here are the most common AWS S3 misconfigurations1.Defining “Full control” access to  Authenticated Aws Users group:

The is perhaps the worst misconfiguration type.  This misconfiguration allows any AWS account, not necessarily yours, the ability to READ and WRITE objects, as well as to VIEW and EDIT policies and permissions for the objects within the bucket. 2. Defining Bucket with a  “read access” policy:

A bucket that allows READ access by authenticated users will provide AWS accounts or IAM users the ability to list all objects within the bucket and use the information acquired to find objects with misconfigured ACL permissions and exploit them.

3.Enabling “Write” access to the “Everyone” group:

This setting also allows anyone to upload, delete or replace objects in the bucket. This can lead to unintended charges on your AWS bill and  far worse it can result in data loss and leakage.

4. Forgetting to encrypt your AWS resources:

Encryption is really important for securing the data. Even if the bucket is unintentionally exposed, the data encryption is another layer of protection. Data should be encrypted both at rest and in transit.


Tip #1:  Make sure you have visibility of all your Amazon S3 resources and audit them for security issues.they should be monitored constantly.

Tip #2:  Block Public Access option from AWS console for all accounts and buckets that you do not want to publicly expose. This feature is a top level security abstraction that contains pre-built policies that will prevent anyone from making the bucket public.

Tip#3: If you provision your own AWS buckets or resources with tools like Terraform  or Cloudformation, make sure you hard-code all the Access list, privileges  and permission groups on your buckets.

Tip#4:  Ensure buckets are encrypted by default, NOTE: keep in mind that if you enable default encryption on an already populated bucket, the existing items won’t be encrypted.

Tip #5:  Minimize the privilege access that you provide to the minimum in order to reduce the risk of errors or malicious intents, avoid giving wildcard permissions and be specific as possible to whom you grant privileges to.

AWS provides many best practices that should be implemented to ensure proper access and authentication. In addition, bucket administrators and  security teams can add additional layers of protection to further restrict who can access it. But even with the best guidelines, protocols and procedures human errors are inevitable.

Just as it is simple to create S3 buckets , it is also very easy to make mistakes in their configuration which can end up in the exposure of all your data to the internet.

Reposify’s latest integration with AWS S3 and EC2 is a great way to automatically monitor all your AWS resources for any security issues and potential exposure. Reposify’s system monitors the EC2 and buckets accounts and notifies you of any misconfiguration or a potential security issue in real-time.

Learn more about Reposify’s AWS integration, request a free personalized demo.

New call-to-action
Tom Bushmitz

Tom Bushmitz is an experienced full-stack engineer, with more than 8 years of experience , working in high volume Cybersecurity startups on different elements and teams within the companies while taking active involvement throughout the development cycle. Proficient in both backend and frontend development SAAS products both on core functionalities, cloud infrastructure environments, 3rd party API integrations and many more.


Share on linkedin
Share on facebook
Share on twitter

Ready to discover your External Attack Surface?

Read Next

Why Only EASM can provide the protection necessary to guard against RCE threat

In April, VMware issued a series of patches to guard against vulnerabilities in a number of products. Among the most critical is CVE-2022-22954, a remote code execution RCE threat that puts organizations at risk of cyber attack. Only EASM can provide thorough cybersecurity protection against remote code execution hacks, with real-time asset monitoring and identification and clear, actionable insights for immediate intervention.

Detect to protect: Reposify’s EASM flags exposed assets vulnerable to Microsoft SMB (CVE-2022-26809)

Microsoft covered more than 100 vulnerabilities in April's security update, among them patches to critical remote code execution (RCE) vulnerabilities located in Microsoft’s SMB. In response Reposify's EASM platform scanned and identified 800,000+ nodes with open SMB protocol on both patched and unpatched systems. Read our latest blog and learn how Reposify's EASM can detect unknown exposed assets vulnerable to Microsoft’s SMB.

Security teams: here’s why you should choose EASM over Shodan?

If you are using Shodan to search for your company’s assets or perform reconnaissance as part of blue or red teams routines - you need to keep reading.