Securing and sharing S3 data

Why S3 security matters

Many well-known data leaks were not clever hacks. Someone made a bucket public "just for a test" and forgot, and search tools found millions of customer records, ID card scans or medical files. S3 is safe by default today, so most leaks come from people switching the safety off. Your job is to keep it private and grant only the access each app needs.

Safe defaults since 2023

• Since April 2023, new buckets have S3 Block Public Access turned on and ACLs disabled.
• Since January 2023, every new object is encrypted at rest with SSE-S3 by default, at no extra cost.

Block Public Access is a set of four switches that override any policy or ACL that would make data public. You can set it per bucket and for the whole account. Keep it on at the account level unless you have a strong, reviewed reason.

Who can do what: IAM policies and bucket policies

An IAM policy is attached to a user, group or role and says what that identity may do, for example "this app role may read objects in invoices-bucket". A bucket policy is a resource-based policy attached to the bucket and names who may access it, which can include other AWS accounts or AWS services. Inside one account, an allow in either place is enough, as long as nothing denies it. For another account, both sides must allow: the bucket policy and the other account's IAM policy. An explicit Deny anywhere always wins.

ACLs (access control lists) are an older, per-object way to grant access. With Object Ownership set to "Bucket owner enforced" (the default for new buckets), ACLs are disabled and the bucket owner owns every object. Use policies instead of ACLs.

A bucket policy for CloudFront

To serve website files publicly but keep the bucket private, put CloudFront (the AWS CDN) in front and use Origin Access Control (OAC). The bucket policy then lets only your CloudFront distribution read objects.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontRead",
      "Effect": "Allow",
      "Principal": { "Service": "cloudfront.amazonaws.com" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::news-site-assets/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
        }
      }
    },
    {
      "Sid": "DenyPlainHttp",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::news-site-assets", "arn:aws:s3:::news-site-assets/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

Static website hosting, and why CloudFront is better

S3 has a "static website hosting" feature that serves index.html from a website endpoint. But that endpoint uses plain HTTP only, and the bucket must allow public reads. CloudFront with OAC gives you HTTPS with your own domain, caching close to users, lower data transfer cost to the internet, and a private bucket. For anything real, use CloudFront.

Encryption choices

Pre-signed URLs: share one file for a short time

A pre-signed URL is a normal S3 link with a signature and an expiry time added. Anyone with the link can download (or upload, if you sign a PUT) that one object until it expires, without an AWS account, and the bucket stays private. The link carries the permissions of whoever signed it, so sign with a role that can only read the needed prefix. With the CLI the default expiry is one hour and the maximum is seven days; links signed with temporary role credentials stop working when those credentials expire.

aws s3 presign s3://lab-reports-ap-south-1/2026/10/report-88231.pdf --expires-in 900

Logging and checking

Turn on S3 server access logs or CloudTrail data events to record who read or changed objects. IAM Access Analyzer can list buckets that are shared outside your account. AWS Config rules and Security Hub can alert you when a bucket becomes public or unencrypted.