The Hidden Dangers of Public S3 Buckets

Amazon Simple Storage Service (S3) buckets have become a cornerstone for businesses and developers seeking scalable, reliable, and cost-effective storage solutions. However, as the adoption of S3 buckets continues to soar, so too does the risk of exposing sensitive data to the public internet due to misconfigurations, vulnerabilities, and evolving attack techniques. In 2025, the dangers of public S3 buckets have reached new heights, with researchers uncovering alarming flaws in AWS's own security tools, sophisticated evasion techniques, and a persistent wave of data breaches stemming from simple yet critical errors. This blog post delves into the latest security risks associated with public S3 buckets, explores real-world incidents from 2025, and provides actionable strategies to safeguard your data.

The Persistent Threat of Misconfigured S3 Buckets

Misconfiguration remains the most pervasive and dangerous issue plaguing S3 buckets in 2025. Despite AWS's ongoing efforts to enhance security features, studies reveal that nearly 50% of S3 buckets are potentially misconfigured, with many inadvertently exposed to the public internet. These misconfigurations often arise from human error, such as overly permissive access control lists (ACLs), incorrect bucket policies, or the failure to enable AWS’s Block Public Access settings. The consequences of such oversights can be catastrophic, leading to unauthorized access, data leaks, and compliance violations.

Understanding S3 Bucket Misconfigurations

To fully grasp the severity of misconfigurations, it's essential to understand the underlying mechanisms that can lead to public exposure. S3 buckets are governed by two primary access control mechanisms: bucket policies and access control lists (ACLs). Both can be misconfigured in various ways, often with devastating results.

Bucket Policies

Bucket policies are JSON documents that define permissions for S3 buckets. They can grant or deny access to specific users, groups, or AWS services. A common mistake is creating a bucket policy that allows public read or write access. For example, a policy like the following would make the entire bucket publicly readable:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

In this example, the Principal field is set to "*", which means any user or service on the internet can access the objects in the bucket. Such a policy can lead to accidental exposure of sensitive data.

Access Control Lists (ACLs)

ACLs are another layer of access control that can be applied to S3 buckets and objects. ACLs define which AWS accounts or groups are granted access and the type of access (e.g., read, write). A common mistake is setting the ACL of a bucket to public-read, which allows anyone on the internet to read the objects in the bucket. For example, the following ACL would make a bucket publicly readable:

<AccessControlPolicy>
  <Owner>
    <ID>...</ID>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:type="Group">
        <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI>
      </Grantee>
      <Permission>READ</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

In this example, the Grantee is set to AllUsers, which means any user on the internet can read the objects in the bucket.

Real-World Incidents in 2025

The year 2025 has already witnessed several high-profile incidents highlighting the risks of public S3 buckets:

Financial Data Exposure

In mid-2025, a publicly readable S3 bucket was discovered containing over 273,000 sensitive financial documents, including customer personal data and bank transfer details. The exposure was not the result of a sophisticated hack but rather a simple misconfiguration that allowed anyone with the bucket’s URL to access its contents. This incident underscores how easily sensitive data can be exposed when proper security controls are overlooked.

The misconfiguration in this case was a bucket policy that granted public read access to the bucket. The policy was likely intended to allow a specific AWS service to access the bucket but was incorrectly written to allow access to anyone on the internet. The bucket was discovered using a simple web search, highlighting the ease with which attackers can find and exploit publicly accessible S3 buckets.

Trusted Advisor Flaw

AWS’s Trusted Advisor, a tool designed to help users identify and remediate security risks, was found to have a critical flaw. Attackers could manipulate bucket policies to make publicly accessible S3 buckets appear secure, effectively bypassing Trusted Advisor’s detection mechanisms. This vulnerability, which was patched by AWS in mid-2025, highlights the limitations of automated security tools and the need for manual oversight.

The flaw exploited a limitation in Trusted Advisor’s ability to detect certain types of bucket policies. By carefully crafting a bucket policy that granted public access in a non-standard way, attackers could make the bucket appear secure to Trusted Advisor while still allowing public access. This demonstrates the importance of not relying solely on automated tools for security and the need for regular manual reviews of bucket configurations.

Evasive Public Access Techniques

Researchers have demonstrated undocumented methods for configuring bucket policies and ACLs that allow buckets to remain publicly accessible while evading detection by AWS’s security tools. These techniques enable attackers to exfiltrate data without triggering alerts, making it even more challenging for organizations to detect and respond to breaches.

One such technique involves using conditional statements in bucket policies to grant public access under specific conditions. For example, a bucket policy might grant public read access only if the request comes from a specific IP address or during a specific time window. Such policies can be difficult to detect using automated tools and may only be discovered through manual review or by an attacker exploiting the misconfiguration.

The Impact of Misconfigurations

The impact of misconfigurations can be far-reaching and severe. Organizations that experience data breaches due to misconfigured S3 buckets may face:

1. Financial Losses: Data breaches can result in significant financial losses due to regulatory fines, legal fees, and the cost of remediation.
2. Reputational Damage: Data breaches can erode customer trust and damage an organization’s reputation, leading to lost business and decreased market share.
3. Regulatory Penalties: Organizations that fail to protect sensitive data may face regulatory penalties and legal action.
4. Operational Disruptions: Data breaches can disrupt business operations, leading to downtime and lost productivity.

The Rise of Advanced Attack Techniques

Beyond misconfigurations, 2025 has seen the emergence of advanced attack techniques targeting S3 buckets. These methods go beyond traditional data leaks and pose even greater risks to organizations:

Supply Chain Attacks

Attackers are increasingly targeting third-party vendors and partners with access to S3 buckets. By compromising a vendor’s credentials or systems, attackers can gain access to an organization’s S3 buckets, leading to data breaches that may go undetected for extended periods.

For example, an attacker might compromise a vendor’s AWS credentials through a phishing attack or by exploiting a vulnerability in the vendor’s systems. Once the attacker has access to the vendor’s credentials, they can use those credentials to access the organization’s S3 buckets, exfiltrate data, or even modify or delete data. Such attacks can be difficult to detect because they originate from a trusted source (the vendor) and may not trigger any security alerts.

Non-Ransomware Attacks

Ransomware gangs have developed new techniques to encrypt data stored in S3 buckets without using traditional ransomware tools. For example, the Codefinger gang has been observed using AWS’s Server-Side Encryption with Customer-Provided Keys (SSE-C) to encrypt data, rendering it inaccessible to organizations unless a ransom is paid. This approach bypasses traditional ransomware detection methods, making it a particularly insidious threat.

In this attack, the Codefinger gang first gains access to an organization’s S3 bucket, either through a misconfiguration or by compromising the organization’s AWS credentials. Once they have access, they use the SSE-C feature to encrypt the data in the bucket using a key that only they possess. The organization is then unable to access its own data and may be forced to pay a ransom to regain access. This attack is particularly dangerous because it uses a legitimate AWS feature to encrypt the data, making it difficult to detect and prevent.

Exploiting VPC Endpoints

Researchers have uncovered methods to exploit Virtual Private Cloud (VPC) endpoints to gain unauthorized access to S3 buckets. By manipulating VPC configurations, attackers can expose S3 buckets without leaving a trace, further complicating detection and response efforts.

For example, an attacker might create a VPC endpoint that allows traffic to flow between a VPC and an S3 bucket. By carefully configuring the endpoint, the attacker can grant public access to the bucket while making it appear as though the access is coming from within the VPC. This can make it difficult for organizations to detect the unauthorized access and may allow the attacker to exfiltrate data without triggering any security alerts.

The Evolution of Attack Techniques

Attack techniques targeting S3 buckets are constantly evolving, making it challenging for organizations to keep up with the latest threats. Some of the most concerning trends in 2025 include:

1. Automated Exploitation: Attackers are increasingly using automated tools to scan for and exploit misconfigured S3 buckets. These tools can quickly identify vulnerable buckets and exfiltrate data before organizations can detect and remediate the misconfigurations.
2. Evasion Techniques: Attackers are developing sophisticated evasion techniques to bypass security controls and avoid detection. For example, attackers may use techniques like DNS tunneling or HTTP header manipulation to exfiltrate data without triggering security alerts.
3. Targeted Attacks: Attackers are increasingly targeting specific organizations or industries with tailored attacks. For example, attackers may target healthcare organizations to steal patient data or financial institutions to steal customer data.
4. Insider Threats: Insider threats, such as disgruntled employees or contractors, can also pose a significant risk to S3 bucket security. Insiders with access to S3 buckets may intentionally or unintentionally expose sensitive data or exfiltrate data for personal gain.

Why Public S3 Buckets Are a Prime Target

Public S3 buckets are an attractive target for cybercriminals for several reasons:

1. Ease of Discovery: Tools like Grayhat Warfare and specialized search engines make it trivial for attackers to scan the internet for publicly accessible S3 buckets. Once discovered, these buckets can be exploited with minimal effort.
2. High-Value Data: S3 buckets often contain sensitive information such as customer data, financial records, intellectual property, and proprietary business information. The potential for financial gain or competitive advantage makes these buckets a lucrative target.
3. Lack of Monitoring: Many organizations fail to implement continuous monitoring for their S3 buckets, allowing attackers to exfiltrate data over extended periods without detection.
4. Complex Permissions: The intricate nature of S3 bucket permissions, which involve a combination of IAM policies, bucket policies, and ACLs, increases the likelihood of misconfigurations that leave data exposed.

How to Protect Your S3 Buckets in 2025

Given the evolving threats and persistent risks, organizations must adopt a multi-layered approach to secure their S3 buckets. Below are the most effective strategies to mitigate the dangers of public S3 buckets:

1. Enable AWS Block Public Access

AWS’s Block Public Access feature is one of the most powerful tools for preventing unintended public exposure of S3 buckets. When enabled, this feature overrides any bucket policies or ACLs that grant public access, ensuring that only authorized users and systems can interact with the bucket. Organizations should enable Block Public Access for all S3 buckets by default and only disable it when absolutely necessary.

To enable Block Public Access, navigate to the S3 console, select the bucket you want to protect, and click on the "Permissions" tab. Under "Block Public Access (bucket settings)", click "Edit" and select the settings you want to enable. AWS recommends enabling all four settings to ensure maximum protection:

1. Block all public access to this bucket
2. Block public access to buckets and objects granted through new access control lists (ACLs)
3. Block public access to buckets and objects granted through any access control lists (ACLs)
4. Block public and cross-account access to this bucket and objects in this bucket through any public bucket or access point policies

2. Implement Least Privilege Access Controls

The principle of least privilege is critical for S3 bucket security. Organizations should:

Use IAM Policies

Define granular IAM policies that restrict access to S3 buckets based on the principle of least privilege. Avoid using wildcard permissions (e.g., \"*\") and instead specify exact actions and resources.

For example, instead of granting a user full access to an S3 bucket with a policy like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

You should grant only the specific permissions that the user needs, such as:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

In this example, the user is granted only the permissions to get and put objects in the bucket, rather than full access to all S3 actions.

Avoid ACLs

While ACLs provide a simple way to manage access, they can lead to misconfigurations. Instead, rely on IAM policies and bucket policies for access control.

For example, instead of using an ACL to grant a user access to a bucket, you should use an IAM policy. ACLs can be difficult to manage and can lead to unexpected access patterns, especially when combined with bucket policies.

Regularly Audit Permissions

Conduct regular audits of IAM policies and bucket policies to identify and remediate overly permissive settings.

You can use AWS’s Access Analyzer to identify and remediate overly permissive policies. Access Analyzer analyzes your policies and generates findings that highlight resources that are shared with external entities. You can then review these findings and update your policies to restrict access as needed.

3. Enable Encryption for Data at Rest and in Transit

Encryption is a fundamental component of S3 bucket security. Organizations should:

Use Server-Side Encryption (SSE)

Enable SSE-S3, SSE-KMS, or SSE-C to encrypt data at rest. SSE-KMS is particularly recommended as it provides additional control over encryption keys.

To enable SSE-S3, you can use the AWS Management Console, AWS CLI, or AWS SDKs. For example, to enable SSE-S3 using the AWS CLI, you can use the following command:

aws s3api put-bucket-encryption --bucket example-bucket --server-side-encryption-configuration '{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "AES256"
      }
    }
  ]
}'

To enable SSE-KMS, you can use the following command:

aws s3api put-bucket-encryption --bucket example-bucket --server-side-encryption-configuration '{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/abcd1234-ab12-ab12-ab12-abcd1234abcd"
      }
    }
  ]
}'

In this example, you replace arn:aws:kms:us-east-1:123456789012:key/abcd1234-ab12-ab12-ab12-abcd1234abcd with the ARN of your KMS key.

Enforce HTTPS

Ensure that all data transmitted to and from S3 buckets is encrypted using HTTPS. This can be enforced by configuring bucket policies to deny HTTP requests.

For example, you can use the following bucket policy to deny HTTP requests:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

In this example, the policy denies all S3 actions if the request is not made using HTTPS (i.e., if aws:SecureTransport is false).

4. Monitor and Audit S3 Buckets Continuously

Continuous monitoring is essential for detecting and responding to unauthorized access and misconfigurations. Organizations should:

Use AWS Security Hub and Macie

These tools provide automated monitoring and alerting for suspicious activities, such as unauthorized access attempts or changes to bucket policies.

AWS Security Hub aggregates security findings from multiple AWS services, including Amazon GuardDuty, Amazon Inspector, and AWS IAM Access Analyzer. You can use Security Hub to view and manage security findings, investigate potential security issues, and take action to remediate them.

Amazon Macie is a machine learning service that helps you discover and protect your sensitive data in AWS. Macie automatically discovers and classifies your data, identifies sensitive data, and provides visibility into your data protection status. You can use Macie to monitor your S3 buckets for sensitive data and receive alerts when sensitive data is accessed or modified.

Enable S3 Access Logs

Configure S3 access logging to track all requests made to your buckets. These logs can be analyzed to detect anomalies and potential breaches.

To enable S3 access logging, you can use the AWS Management Console, AWS CLI, or AWS SDKs. For example, to enable S3 access logging using the AWS CLI, you can use the following command:

aws s3api put-bucket-logging --bucket example-bucket --bucket-logging-status '{
  "LoggingEnabled": {
    "TargetBucket": "example-log-bucket",
    "TargetPrefix": "logs/"
  }
}'

In this example, you replace example-log-bucket with the name of the bucket where you want to store the access logs, and logs/ with the prefix you want to use for the log files.

Set Up Alerts for Public Access

Use AWS Config and Amazon EventBridge to create alerts that notify you whenever a bucket is configured for public access.

To set up alerts for public access using AWS Config, you can create a custom rule that checks for buckets that are publicly accessible. For example, you can use the following AWS Config rule to check for buckets that are publicly accessible:

{
  "ConfigRuleName": "public-bucket-check",
  "Description": "Checks for S3 buckets that are publicly accessible",
  "Scope": {
    "ComplianceResourceTypes": ["AWS::S3::Bucket"]
  },
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"
  },
  "InputParameters": {}
}

In this example, the rule checks for S3 buckets that are publicly accessible and generates a compliance finding if a bucket is found to be publicly accessible. You can then use Amazon EventBridge to create an event rule that triggers an action (e.g., sending an email notification) when a compliance finding is generated.

5. Regularly Review and Update Security Practices

Security is not a one-time effort but an ongoing process. Organizations should:

Conduct Regular Security Assessments

Perform periodic security assessments and penetration tests to identify vulnerabilities in your S3 bucket configurations.

You can use AWS’s penetration testing guidelines to conduct security assessments of your S3 buckets. AWS allows penetration testing of your AWS infrastructure, but you must follow AWS’s guidelines to ensure that your testing does not disrupt AWS services or violate AWS’s acceptable use policy.

Stay Informed About AWS Updates

AWS frequently releases new security features and updates. Stay informed about these changes and implement them as needed to enhance your security posture.

You can stay informed about AWS updates by subscribing to AWS’s security bulletins, following AWS’s security blog, and attending AWS security webinars and events. AWS also provides a security and compliance documentation center that you can use to learn about AWS’s security features and best practices.

Train Employees

Human error is a leading cause of misconfigurations. Provide regular training to employees and developers on S3 security best practices and the risks of public exposure.

You can use AWS’s security training and certification programs to train your employees on S3 security best practices. AWS offers a variety of training programs, including online courses, classroom training, and hands-on labs. You can also use AWS’s security documentation and whitepapers to supplement your training programs.

6. Leverage Third-Party Security Tools

In addition to AWS’s native security features, organizations can benefit from third-party tools designed to enhance S3 bucket security. These tools often provide advanced monitoring, automated remediation, and additional layers of protection against evolving threats.

For example, you can use third-party tools like CloudCheckr, DivvyCloud, and Prisma Cloud to monitor your S3 buckets for misconfigurations and security risks. These tools provide advanced features like automated remediation, compliance reporting, and anomaly detection. You can use these tools to supplement AWS’s native security features and enhance your overall security posture.

The Role of AWS in Mitigating Risks

AWS has taken significant steps to address the risks associated with public S3 buckets. In 2025, AWS introduced several enhancements to its security tools, including:

Improved Trusted Advisor Checks

Following the discovery of the Trusted Advisor flaw, AWS enhanced its detection mechanisms to better identify publicly accessible S3 buckets and prevent evasion techniques.

AWS’s Trusted Advisor is a tool that provides recommendations for improving the security, performance, and cost efficiency of your AWS environment. Trusted Advisor analyzes your AWS environment and generates recommendations based on AWS’s best practices. You can use Trusted Advisor to identify and remediate security risks, such as publicly accessible S3 buckets.

Enhanced Block Public Access

AWS has expanded the Block Public Access feature to cover more scenarios, making it harder for users to inadvertently expose their buckets.

AWS’s Block Public Access feature is designed to prevent unintended public exposure of S3 buckets. When enabled, this feature overrides any bucket policies or ACLs that grant public access, ensuring that only authorized users and systems can interact with the bucket. AWS has enhanced this feature to cover more scenarios, such as preventing public access to buckets through VPC endpoints.

New Security Alerts

AWS Security Hub now includes additional alerts for suspicious activities related to S3 buckets, such as unusual access patterns or changes to encryption settings.

AWS Security Hub is a service that provides a comprehensive view of your security and compliance posture across AWS. Security Hub aggregates security findings from multiple AWS services, including Amazon GuardDuty, Amazon Inspector, and AWS IAM Access Analyzer. You can use Security Hub to view and manage security findings, investigate potential security issues, and take action to remediate them. AWS has added new alerts to Security Hub to help you detect and respond to suspicious activities related to S3 buckets.

The hidden dangers of public S3 buckets in 2025 are more pronounced than ever, with misconfigurations, advanced attack techniques, and flaws in security tools creating a perfect storm for data breaches. However, by adopting a proactive and multi-layered approach to security, organizations can significantly reduce their risk exposure. Enabling Block Public Access, implementing least privilege access controls, encrypting data, continuously monitoring buckets, and staying informed about the latest threats are all critical steps in protecting your S3 data.

As cloud storage continues to play a central role in modern business operations, the responsibility to secure it falls on both cloud providers and users. AWS is continually improving its security features, but ultimately, it is up to organizations to configure and manage their S3 buckets securely. By taking the necessary precautions and remaining vigilant, you can safeguard your data and mitigate the risks posed by public S3 buckets in 2025 and beyond.

Final Thoughts

The risks associated with public S3 buckets are not just theoretical—they are real, evolving, and increasingly sophisticated. Organizations that fail to prioritize S3 security risk not only data breaches but also reputational damage, financial losses, and regulatory penalties. Now is the time to assess your S3 bucket configurations, implement robust security measures, and ensure that your data remains protected in an ever-changing threat landscape.

Also read:

• Understanding Zero Trust Architecture

• Cloud Regions vs. Availability Zones: Key Differences and Best Practices for 2025

• Multi-Cloud Security: Best Practices for Securing Serverless Architectures in 2025