Start Free Trial

AWS S3 bucket security: find public buckets before anyone else does

Misconfigured S3 buckets are one of the most common causes of cloud data exposure. A single bucket policy or ACL change can make customer files readable by anyone on the internet. bearhug brings together the S3 findings Security Hub reports across every connected AWS account, explains the risk in plain English and fixes public access in one click.

S3 security best practices bearhug checks

Depending on the AWS Security Hub standards you have enabled, bearhug surfaces findings for S3 best practices such as these.

CheckWhy it matters
Block Public Access enabled at account and bucket levelStops a single policy or ACL change from exposing a bucket to the internet.
No bucket policies granting access to everyone (*)A wildcard principal makes objects readable, or writable, by anyone.
Server access logging or CloudTrail data eventsGives you a record of who accessed which objects, which any investigation needs.
SSL-only access enforced in the bucket policyPrevents data being sent to or from the bucket over unencrypted connections.
Versioning and MFA delete on critical bucketsProtects against accidental deletion and malicious overwrites.

Why S3 buckets become public by accident

Most exposed buckets were not made public on purpose. A developer opens access to share a file with a partner, a static website is hosted directly from a bucket, or an infrastructure template copies a permissive policy from an old example. Each change makes sense at the time, and nobody remembers to close it again.

S3 access is controlled in several places: account-level Block Public Access, bucket-level settings, bucket policies and object ACLs. It is easy to fix one and miss another. That is why continuous checks matter more than a one-off review.

How to check your S3 buckets manually

  1. In the AWS console, open Amazon S3 and look at the Access column in the bucket list. Any bucket marked Public or Objects can be public needs a closer look.
  2. Open Block Public Access settings for this account. All four options should normally be turned on.
  3. For a single bucket, check its Block Public Access configuration with the AWS CLI:
    aws s3api get-public-access-block --bucket example-bucket
  4. Check whether the bucket policy makes the bucket public. An IsPublic value of true means it does:
    aws s3api get-bucket-policy-status --bucket example-bucket
  5. Check which encryption the bucket applies to new objects. Since January 2023 this is at least SSE-S3; look for aws:kms if you expect AWS KMS keys:
    aws s3api get-bucket-encryption --bucket example-bucket
  6. Repeat for every bucket, in every account, every time something changes.

The last step is where manual checks break down. A review that was accurate on Monday can be out of date by Tuesday.

How bearhug automates it

Connect your AWS account, and bearhug lists every bucket that Security Hub reports with a public-access or bucket policy finding, ranked by severity and explained in plain English. Which checks run depends on the Security Hub standards and regions you have enabled.

For public access, click Fix to enable Block Public Access on the bucket, with rollback if an application relies on the old setting. For other findings, bearhug gives step-by-step guidance generated with Amazon Bedrock.

Because findings stream in continuously, a bucket that becomes public after your review is flagged as soon as AWS reports it, and a new critical finding triggers an email alert. See more one-click AWS remediation examples.

Protecting S3 data beyond public access

Blocking public access is the most important S3 control, but it is not the only one. AWS has tightened the defaults over time: since April 2023, new buckets have Block Public Access turned on and access control lists (ACLs) disabled by default. Buckets created before then, and buckets created from older templates, may still use the old settings.

A well-configured bucket usually has the following in place:

  • Encryption at rest. Since January 2023, S3 encrypts every new object by default with Amazon S3 managed keys (SSE-S3). Objects uploaded before then may still be unencrypted. Sensitive data may call for AWS KMS keys (SSE-KMS or DSSE-KMS), which add key-level access control and audit logging.
  • ACLs disabled. With S3 Object Ownership set to Bucket owner enforced, access is controlled by policies alone, which is far easier to reason about.
  • Least-privilege bucket policies. Grant access to specific IAM roles or AWS accounts rather than broad principals, and require TLS for every request.
  • Logging. Server access logs or CloudTrail data events record who accessed which objects, which you need to investigate any incident.
  • Versioning on important buckets. Versioning lets you recover objects that are deleted or overwritten by mistake.

Serving public content safely

Some buckets need to serve files to the public, such as website assets or downloads. The safer pattern is to keep the bucket private and put Amazon CloudFront in front of it, using origin access control so that only your CloudFront distribution can read from the bucket.

Origin access control works with the bucket as a CloudFront origin, not with the S3 static website endpoint. If a site currently uses the website endpoint, switch the origin to the bucket, set a default root object and error pages in CloudFront, add a CloudFront Function if you need index documents in subfolders, and confirm the site works before you turn on Block Public Access.

This keeps public access switched off on the bucket itself, so a single policy change can no longer expose everything in it, and it gives you caching and HTTPS as well.

S3 security across every account

Most teams have buckets in more than one AWS account: production data, staging copies, logs and backups. bearhug brings the S3 findings from every connected account into one multi-account AWS security dashboard, so a public bucket in a forgotten test account is as visible as one in production.

S3 bucket security questions

It can, if the website is served directly from an S3 bucket or its S3 website endpoint. Before you apply the fix, serve the site through Amazon CloudFront using the bucket itself as the origin, rather than the website endpoint, with origin access control. Recreate any website behaviour you relied on, such as a default root object and error pages, and check the site works before you block public access.

No. bearhug works with security settings and findings from your account. It does not read the contents of your files.

bearhug works in any AWS Region where Security Hub is available. S3 findings come from the Regions where Security Hub is enabled and the controls you have turned on, and some controls are not available in every Region.

bearhug costs $100 per AWS account per month, however many buckets the account holds. Every feature is included.

Connect in five minutes and start checking every S3 bucket

14-day free trial. The paid plan is $100 per AWS account per month, billed through AWS Marketplace.

No credit card. No procurement. Starts from your AWS console.