Securing Amazon S3: Understanding Public Access and Bucket Permissions
Amazon S3 makes it easy to store and retrieve data, but misconfigured permissions can expose sensitive information. In this article, I explore S3 Block Public Access, bucket policies, IAM permissions, and practical ways to reduce the risk of accidental data exposure while learning cloud security.
Series: AWS Cybersecurity Learning Series (5 articles)
- …
- 5Securing Amazon S3: Understanding Public Access and Bucket Permissions This article
Securing Amazon S3: Understanding Public Access and Bucket Permissions
While learning AWS security, I started noticing how many security concepts connect to one another. In my previous article, I explored Amazon VPC security groups and how they control network traffic. This time, I wanted to understand another important question:
What happens when the network is secure, but the data itself has the wrong permissions?
Amazon Simple Storage Service (Amazon S3) is widely used to store files, application data, backups, logs, and other objects. However, storing data securely requires more than simply creating a bucket. Its permissions must ensure that only the intended users and applications can access the information.
In this article, I'll explore common S3 access controls, the risks of accidental public exposure, and a few practical security checks that are useful for anyone learning cloud security.
1. Understanding S3 buckets and objects
Amazon S3 stores data as objects inside buckets. A bucket acts as a container, while an object represents the stored data and its associated metadata.
For example, imagine an application that stores uploaded documents in a bucket named
my-learning-bucket.An object might be addressed using this structure:
1
2
Bucket: my-learning-bucket
Object: reports/annual-report.pdfThe bucket and its objects can have different access-control considerations. A secure configuration must account for who can list objects, read files, upload new content, or delete existing data.
A file being stored in S3 does not automatically mean that it should be accessible to everyone on the internet.
2. What does public access actually mean?
A public S3 resource may allow people without the intended AWS identity or authorization to access data.
The impact depends on the permissions granted. Public read access can expose files, while public write access can create much more serious risks, including unauthorized uploads, content modification, or deletion when the corresponding permissions allow those actions.
This is why it's important to distinguish between different S3 actions:
s3:ListBucket— allows listing objects in a bucket, subject to the applicable resource and policy configuration.s3:GetObject— allows reading an object.s3:PutObject— allows uploading or replacing an object.s3:DeleteObject— allows deleting an object.
These permissions are not interchangeable. A user who needs to download a report does not necessarily need permission to upload or delete files.
This connects directly to the principle of least privilege that I explored earlier with AWS IAM.
3. S3 Block Public Access: A critical safety layer
One of the most important features to understand is S3 Block Public Access.
Amazon S3 enables Block Public Access by default for new buckets. These settings help prevent public access from being granted through supported public ACLs and policies.
The four settings are:
- BlockPublicAcls: Blocks new public access control lists and certain requests that attempt to apply them.
- IgnorePublicAcls: Causes public ACL permissions to be ignored.
- BlockPublicPolicy: Blocks new bucket or access-point policies that grant public access.
- RestrictPublicBuckets: Restricts certain access to buckets with public policies.
These settings work together with the applicable account-level and organization-level settings. S3 applies the most restrictive effective configuration.
An important distinction: Block Public Access is not a replacement for reviewing permissions. It is a protective control that helps prevent unintended public exposure.
For most private data buckets, leaving all four settings enabled is a sensible starting point.
4. Understanding bucket policies
A bucket policy is a resource-based policy that defines which principals can perform which actions on an S3 resource.
For example, a policy may allow a particular IAM role to read objects from a bucket without granting that role unnecessary write or delete permissions.
A policy statement generally includes:
- Effect: Whether the statement allows or denies an action.
- Principal: The identity to which the statement applies.
- Action: The operation being allowed or denied.
- Resource: The bucket or object covered by the statement.
- Condition: Optional requirements that a request must satisfy.
A common warning sign is a wildcard principal such as
"Principal": "*", particularly when combined with permissions that expose sensitive data.However, a wildcard should always be evaluated in context. The actual effect depends on the complete policy, the actions and resources specified, applicable conditions, and other access controls.
For private application data, access should normally be limited to the identities and actions that the application actually requires.
5. IAM policies versus S3 bucket policies
This was another useful distinction for me while studying AWS.
IAM identity-based policies attach permissions to identities, such as users, groups, and roles.
S3 bucket policies attach to a bucket and specify which principals can access that resource and what they can do.
For example, an application running on an EC2 instance might use an IAM role to read files from a specific S3 bucket. The role's permissions and the bucket's resource policy, if one is used, should be designed together.
A simplified access model looks like this:
1
2
3
4
5
6
7
8
9
10
11
Application on EC2
|
v
IAM Role
|
| Only required S3 actions
v
S3 Bucket
|
v
ObjectsThe goal is not to give the application broad access to every bucket in the account. It is to grant only the permissions required for its task.
AWS authorization can involve several policy types and controls, so the effective result depends on the complete request context rather than a single policy viewed in isolation.
6. A practical security checklist
When reviewing an S3 bucket, I would start with these checks:
1. Review Block Public Access
Check the bucket's public-access settings and understand whether account-level or organization-level controls also apply.
2. Inspect the bucket policy
Look for unexpected wildcard principals, broad actions, and resources that are wider than necessary.
3. Review IAM permissions
Check which users and roles can list, read, upload, or delete objects. Remove unnecessary permissions where appropriate.
4. Understand object ownership and ACLs
S3 Object Ownership defaults to Bucket owner enforced for new buckets, which disables ACLs. For most modern use cases, AWS recommends policy-based access management rather than relying on ACLs.
5. Consider monitoring and recovery
IAM Access Analyzer for S3 can help identify unintended access. S3 Versioning can help preserve previous object versions when data is overwritten or deleted, although versioning is not a substitute for access control or a complete backup strategy.
6. Avoid unnecessary changes to public-access settings
Never disable protective settings just to make an access error disappear. First identify why the request is being denied and determine the intended access model.
7. A safe learning exercise
For a hands-on learning exercise, I would use a bucket that contains only non-sensitive test files.
The exercise could involve:
- Creating a test S3 bucket with Block Public Access enabled.
- Uploading a harmless sample text file.
- Reviewing the bucket's permissions and public-access status.
- Examining a sample bucket policy and identifying the principal, action, resource, and effect.
- Reviewing how a narrowly scoped IAM role could be granted read access to the test object.
- Confirming that the intended identity can perform its task without receiving unnecessary permissions.
I would perform these checks only in an AWS account I own or am authorized to use. There is no need to expose a real bucket publicly to learn how public-access controls work.
The important outcome is understanding the difference between an access denial caused by a protective control and a genuinely incorrect permission configuration.
Conclusion
One of my biggest takeaways from learning S3 security is that cloud storage security depends heavily on authorization decisions. A bucket may be configured correctly at first, but its policies and permissions still need to be reviewed as an application evolves.
Block Public Access, least-privilege IAM permissions, carefully written bucket policies, and access monitoring all contribute to a stronger configuration.
I'm continuing to explore how AWS services fit together from a cybersecurity perspective. After learning about IAM, CloudTrail, GuardDuty, and Security Groups, S3 security adds another important piece to the picture: protecting the data that cloud infrastructure is built to store.
Official AWS resources
Series: AWS Cybersecurity Learning Series (5 articles)
- …
- 5Securing Amazon S3: Understanding Public Access and Bucket Permissions This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article