AWS S3 Security: Common Misconfigurations and How to Fix Them

Learn how to secure Amazon S3 buckets by fixing common misconfigurations involving public access, IAM policies, bucket policies, encryption, object ownership, logging, versioning, and data protection.

Amazon S3 is widely used for storing application data, backups, logs, media files, static websites and business-critical documents. Because S3 can store large amounts of sensitive information, incorrect access controls can create serious security risks.

Many S3 security problems are not caused by a vulnerability in S3 itself. They are usually the result of incorrect bucket policies, excessive permissions, public access settings, weak encryption configuration, poor credential management or missing monitoring.

In this guide, we will cover 10 common Amazon S3 security misconfigurations, explain why they are risky and show practical ways to fix them.

How S3 Security Works

S3 access can involve several layers of AWS security controls.


User / Application
       |
       v
IAM Identity / Role
       |
       v
IAM Policy
       |
       v
S3 Bucket Policy
       |
       v
Block Public Access
       |
       v
S3 Object

Depending on the request, additional controls such as encryption, object ownership, VPC endpoints, access points, logging and monitoring can also be involved.

1. S3 Bucket Is Accidentally Public

One of the most common S3 security concerns is unintended public access.

A bucket or its objects may become publicly accessible because of a bucket policy, access point configuration, ACL configuration or other access settings.

For private data, the recommended approach is to keep public access disabled unless there is a specific business requirement for public access.

Check Block Public Access

aws s3api get-public-access-block \
  --bucket example-bucket

A private bucket should normally have the relevant S3 Block Public Access settings enabled.

AWS provides four Block Public Access settings:

BlockPublicAcls
IgnorePublicAcls
BlockPublicPolicy
RestrictPublicBuckets

These controls are designed to help prevent public access from being introduced accidentally.

2. Overly Permissive Bucket Policy

An S3 bucket policy can grant access to AWS accounts, users, roles or, depending on the policy, broad principals.

A dangerous pattern is granting broad access to everyone when the bucket contains private information.

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-bucket/*"
}

This effectively makes the objects readable by a broad set of principals and should only be used when public access is explicitly intended.

For private application data, restrict the principal and actions to the identities that actually require access.

3. IAM Policy Grants Excessive S3 Permissions

Bucket policies are not the only source of access. IAM policies attached to users and roles can also provide S3 permissions.

Avoid giving an application unrestricted permissions such as:

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

Instead, follow the principle of least privilege.

For example, an application that only needs to download objects may require a much smaller permission set:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject"
  ],
  "Resource": "arn:aws:s3:::example-bucket/application/*"
}

The exact permissions should be based on what the application actually needs.

4. Object Ownership and ACLs Are Misconfigured

Amazon S3 supports Object Ownership settings that can simplify access management by disabling ACL-based access control for buckets where ACLs are not required.

Bucket owner enforced is the recommended Object Ownership setting for most modern S3 use cases where ACLs are not needed.

Check the current configuration:

aws s3api get-bucket-ownership-controls \
  --bucket example-bucket

Using a consistent ownership model reduces confusion between IAM policies, bucket policies and object ACLs.

5. S3 Data Is Not Properly Encrypted

Encryption is an important layer of data protection.

Amazon S3 supports server-side encryption options, including Amazon S3 managed keys and AWS Key Management Service (SSE-KMS).

Check the bucket's default encryption configuration:

aws s3api get-bucket-encryption \
  --bucket example-bucket

For workloads with specific key-management, auditing or compliance requirements, SSE-KMS may be appropriate.

Remember that protecting S3 data with KMS also means protecting the KMS key and controlling which identities can use it.

6. Encryption Key Permissions Are Too Broad

Using SSE-KMS improves control over encryption, but the KMS key policy and IAM permissions must also be secured.

An application that can read encrypted S3 objects may require permission to use the relevant KMS key depending on the encryption configuration.

Review:

KMS key policy
IAM permissions
Key administrators
Key users
Cross-account access
Key rotation requirements

Do not give every administrator unrestricted access to every encryption key.

7. Versioning Is Disabled for Important Data

S3 Versioning maintains multiple versions of objects and can help recover from accidental overwrites or deletions.

Check versioning:

aws s3api get-bucket-versioning \
  --bucket example-bucket

For important data, versioning can provide an additional recovery mechanism.

However, versioning is not a complete ransomware-protection strategy. If an attacker has permissions to delete object versions, additional controls such as retention and immutability may be required.

8. No Lifecycle Policy for Old Data

Security and cost management are closely related when operating large S3 environments.

Old objects, previous versions and incomplete multipart uploads can accumulate over time.

S3 Lifecycle rules can help automate actions such as transitioning objects to different storage classes or deleting data after an approved retention period.

Before creating deletion rules, make sure they match the organization's data-retention and recovery requirements.

9. Logging and Monitoring Are Missing

Access controls help prevent unauthorized access, but monitoring helps you detect suspicious activity.

Depending on the environment, useful AWS security and monitoring services can include:

AWS CloudTrail
Amazon CloudWatch
Amazon GuardDuty
IAM Access Analyzer
Amazon Macie

CloudTrail can help record API activity, while Amazon Macie can help discover and monitor sensitive data stored in S3.

10. S3 Bucket Is Accessible From Untrusted Networks

Not every S3 workload needs unrestricted network access.

For applications running inside AWS, consider using an S3 VPC endpoint so that application traffic can reach S3 through the AWS network without requiring a public internet path.


Private EC2
    |
    v
VPC
    |
    v
S3 VPC Endpoint
    |
    v
Amazon S3

Endpoint policies and bucket policies can then be used to further restrict access according to the application's requirements.

11. Avoid Hard-Coded S3 Credentials

Applications should not contain permanent AWS credentials in source code or configuration files.

Avoid:

AWS_ACCESS_KEY_ID=xxxxxxxx
AWS_SECRET_ACCESS_KEY=xxxxxxxx

For AWS workloads, use IAM roles and temporary credentials whenever possible.

For example:


EC2 / Lambda / ECS
       |
       v
IAM Role
       |
       v
Temporary Credentials
       |
       v
S3 Bucket

12. Restrict S3 Access to Specific VPC Endpoints

For private workloads, an S3 bucket policy can sometimes be designed to restrict access to a specific VPC endpoint.

A conceptual policy condition can look like:

"Condition": {
  "StringEquals": {
    "aws:sourceVpce": "vpce-xxxxxxxxxxxxxxxxx"
  }
}

This should only be implemented after carefully understanding which clients need access. An incorrectly configured condition can block legitimate applications.

13. Protect Backup Buckets From Deletion

S3 is frequently used for backups, logs and disaster recovery data.

A backup bucket should not necessarily have the same access model as a normal application bucket.

For important backups, consider:

Separate AWS accounts.
Restricted administrative access.
Versioning.
S3 Object Lock where appropriate.
Encryption.
Monitoring.
Independent recovery procedures.

14. Use S3 Object Lock for Immutable Data

S3 Object Lock can prevent objects from being overwritten or deleted for a defined retention period.

This is particularly useful for compliance records and ransomware-resistant backup architectures.


Application Backup
       |
       v
S3 Bucket
       |
       v
Object Lock
       |
       v
Immutable Object
       |
       v
Recovery

Retention requirements should be defined before enabling immutability because retention controls can affect how data is managed and deleted.

15. Use IAM Access Analyzer

IAM Access Analyzer can help identify resources that are accessible outside intended trust boundaries and can help analyze policies.

Use it as part of regular access reviews.

Pay particular attention to findings involving:

Public access
Cross-account access
Unexpected principals
Broad resource policies

How to Audit an S3 Bucket

When investigating an S3 bucket, start with a basic configuration review.

Check Bucket Location

aws s3api get-bucket-location \
  --bucket example-bucket

Check Public Access Block

aws s3api get-public-access-block \
  --bucket example-bucket

Check Bucket Policy

aws s3api get-bucket-policy \
  --bucket example-bucket

Check Versioning

aws s3api get-bucket-versioning \
  --bucket example-bucket

Check Encryption

aws s3api get-bucket-encryption \
  --bucket example-bucket

Check Ownership Controls

aws s3api get-bucket-ownership-controls \
  --bucket example-bucket

S3 Security Review Checklist

S3 Block Public Access is enabled where public access is not required.
Bucket policies are reviewed for broad principals.
IAM permissions follow least privilege.
Object Ownership is configured appropriately.
ACLs are avoided where they are unnecessary.
Default encryption is enabled.
KMS permissions are restricted where SSE-KMS is used.
Versioning is enabled where appropriate.
Lifecycle rules match retention requirements.
CloudTrail monitoring is configured as required.
IAM Access Analyzer findings are reviewed.
Sensitive data is identified and protected.
Applications use IAM roles rather than hard-coded credentials.
Backup buckets are separated and protected.
Object Lock is considered for immutable data.
S3 access is reviewed regularly.

Common S3 Security Mistakes

Making a Bucket Public to Fix an Access Problem

A common troubleshooting mistake is making a private bucket public simply because an application cannot access it.

Instead, identify the application identity and grant only the required permissions.

Using AdministratorAccess for Applications

Applications should not normally run with broad administrator permissions just because it is convenient during development.

Ignoring Object Ownership

Legacy ACL-based configurations can make S3 permissions harder to understand. Use a clear ownership model appropriate for the workload.

Assuming Encryption Solves Access Control

Encryption protects data from certain forms of unauthorized access, but it does not replace IAM authorization, bucket policies or monitoring.

Never Reviewing Old Bucket Policies

S3 policies can remain unchanged for years even after the original application or access requirement has disappeared. Regular access reviews are essential.

Recommended Secure S3 Architecture


                 AWS Account
                     |
              IAM / IAM Role
                     |
                     v
              Application
                     |
                     v
              VPC Endpoint
                     |
                     v
              S3 Bucket
                     |
       +-------------+-------------+
       |             |             |
       v             v             v
 Encryption      Versioning    Monitoring
       |             |             |
       +-------------+-------------+
                     |
               Access Controls
                     |
       +-------------+-------------+
       |                           |
       v                           v
 Block Public Access       Bucket Policy
                                   |
                                   v
                            Least Privilege

Final Thoughts

Securing Amazon S3 is primarily about controlling access, protecting data and continuously monitoring how the storage environment is being used.

Start with the fundamentals: Block Public Access, least-privilege IAM policies, secure bucket policies, appropriate Object Ownership, encryption and strong credential management.

For more sensitive environments, add additional controls such as VPC endpoints, CloudTrail monitoring, IAM Access Analyzer, Macie, versioning and S3 Object Lock.

The most important lesson is that S3 security should be reviewed continuously. A bucket that is secure today can become exposed later when a policy, application or access requirement changes.

Regular security reviews and automated guardrails can help prevent configuration drift and reduce the risk of accidental data exposure.