Amazon S3 (Amazon Simple Storage Service) is an object storage service. It is the most popular public cloud service that offers data availability, security, and performance. It is used by both small and large businesses. To automatically monitor all your AWS resources for any security issues and potential exposure, AWS S3 is a great way to do it. You can use many online tools to find S3 buckets on a website.
2026 update — read this before the list: AWS changed two major S3 defaults in 2023, and they affect roughly half the items below.
This article was written when every new S3 bucket was created “open” and you had to remember to lock it down. That is no longer true. Two AWS changes reshaped S3 security, and you must understand them so you do not act on outdated assumptions:
- Block Public Access is ON by default for new buckets (since April 27, 2023). Every new bucket, in every Region, is created with all four Block Public Access settings enabled. A bucket is no longer public “by accident” the way it used to be — you now have to deliberately turn protection off to expose it. The public-access items below (public READ, public WRITE, public via policy, public FULL_CONTROL) are therefore prevented by default; treat them as “confirm the default is still on and account-level Block Public Access is enabled” rather than “remember to enable it.”
- ACLs are DISABLED by default for new buckets (since April 27, 2023). New buckets are created with S3 Object Ownership set to Bucket owner enforced, which turns off ACLs entirely. Access is then controlled only by IAM policies and bucket policies. This is the big one: every ACL-based item in this list — authenticated-users READ/WRITE, READ_ACP, WRITE_ACP, FULL_CONTROL via ACLs — no longer applies to a modern bucket, because ACLs are not evaluated at all when they are disabled. Those items are still worth understanding for old buckets created before 2023 (where ACLs may still be enabled), but for anything new the correct action is simply “keep ACLs disabled,” which AWS already does for you.
On top of those, a third change matters for the encryption items: all S3 buckets are encrypted by default (since January 5, 2023). SSE-S3 is applied automatically to every new object at no cost. See the inline notes on the encryption items below.
The practical 2026 summary: control S3 access with IAM policies and bucket policies, keep account-level Block Public Access turned on, keep ACLs disabled, and use AWS Access Analyzer for S3 to catch any bucket that is actually exposed. The individual checks below are still valid as detections — but the platform now does most of this by default, so the failure mode has shifted from “forgot to lock it down” to “someone deliberately loosened a default.”
Here are a few AWS S3 Misconfigurations that you can avoid in 2023.
-
Access Logging Enabled
The first thing in AWS S3 Misconfigurations is not having S3 bucket access logging enabled on the CloudTrail S3 bucket. It is crucial to check S3 bucket access logging is enabled on the CloudTrail S3 bucket. Furthermore, taking care of these s3 misconfigurations helps you comply with the following compliance standards – CIS,SOC2,PCI,HIPAA,APRA,MAS,GDPR, and NIST.
2026 update — know the difference between the two kinds of S3 logging, and prefer CloudTrail data events for security. This item is still valid, but in 2026 you should be clear on which logging you mean, because they answer different questions:
- S3 server access logging (what this item describes) writes best-effort log records to a target bucket. It is useful for access patterns and billing analysis but is delivered on a delay and is not guaranteed complete.
- CloudTrail data events for S3 capture object-level API activity (GetObject, PutObject, DeleteObject) with the caller identity, and deliver into your CloudTrail pipeline where GuardDuty and Security Hub can analyze them in near real time. For detecting exfiltration or unauthorized access, this is the stronger choice.
Best practice today is to enable CloudTrail data events on buckets holding sensitive data (be mindful of cost on high-traffic buckets and scope selectors accordingly), and keep server access logging where you need request-level analytics. Whichever you use, make sure the log destination bucket itself is not public and is protected from deletion.
-
S3 Buckets Public Access Block
To avoid any S3 misconfigurations, ensure that your S3 bucket used to store CloudTrail logs is not publicly accessible — a publicly readable bucket is a classic internet-exposed asset. Monitoring the use of information system accounts will provide better security, the kind of visibility teams gain when securing multi-account AWS without a landing zone or Control Tower.
2026 update — enforce Block Public Access at the account level, not just per bucket. Since April 2023 new buckets get Block Public Access enabled automatically, but the strongest guarantee is to turn on account-level Block Public Access (S3 console → Block Public Access settings for this account → enable all four). That override applies to every bucket in the account — existing and future — so no individual bucket can be made public even if someone changes its settings. Do this once and the “is my bucket public?” question is answered for the whole account. Continue to confirm it stays on, ideally via AWS Config or Security Hub CSPM, which flag it if it is ever disabled.
-
S3 Bucket Default Encryption
This S3 Misconfiguration Ensure that your S3 buckets have default encryption (SSE) enabled, or they are using a bucket policy to enforce it. Having this configuration can improve your security standards. This is also one step closer to being PCI, HIPAA, GDPR, MAS, NIST, and APRA compliant, and a core part of a broader data security posture.
2026 update — every S3 bucket is now encrypted by default, so “SSE not enabled” is no longer possible. Since January 5, 2023, Amazon S3 automatically applies server-side encryption with S3-managed keys (SSE-S3) to every new object in every bucket, at no additional cost and with no performance impact. You cannot have an unencrypted-at-rest bucket anymore; the baseline is guaranteed. So the check shifts from “is encryption on?” to “is it the right encryption for my compliance needs?” For sensitive or regulated data, upgrade the default from SSE-S3 to SSE-KMS with a customer-managed KMS key, which gives you key rotation, per-key access control, and CloudTrail logging of every decrypt — the things auditors for PCI, HIPAA, and GDPR actually want to see. You can also enforce a specific encryption type by denying uploads that lack it in the bucket policy.
-
S3 HTTPS Only
Another S3 misconfiguration is if your S3 buckets do not have a secure transport policy. Having S3 buckets with a secure transport policy can help you achieve PCI, SOC2, APRA, MAS, HIPAA, and NIST compliance.
2026 update — this is still one of the most important checks, and you can now also enforce a minimum TLS version. S3 does not force HTTPS on its own, so you must add a bucket policy that denies any request where
aws:SecureTransportisfalse— that part of the advice is unchanged and still essential. What is newer: you can also require a modern TLS version by denying requests where thes3:TlsVersioncondition key is below 1.2 (and TLS 1.3 is supported), which protects you against downgrade attacks and satisfies auditors who now expect TLS 1.2 as a floor. Add both conditions to your bucket policy so that data-in-transit protection is explicit and provable, not assumed.
-
S3 Does Not Allow Public Writes
S3 Misconfigurations can be avoided by checking if S3 buckets have policies that allow public WRITE access. Having S3 buckets with policies that allow public WRITE access violates the PCI, APRA, MAS, and NIST compliance standards.
-
S3 Bucket Authenticated Users WRITE Access
Building on the above S3 misconfiguration, another very common misconfiguration is allowing WRITE access to AWS authenticated users. You must ensure S3 buckets do not allow WRITE access to AWS authenticated users through S3 ACLs.
2026 update — this item and all the ACL-based items that follow (READ, READ_ACP, WRITE_ACP, FULL_CONTROL “via ACLs” / “to authenticated users”) are effectively obsolete for buckets created after April 2023, because ACLs are disabled by default.
A quick, clear explanation so nothing is left to assumption. “AWS authenticated users” in the ACL context means any AWS account holder in the world — not just users in your account — which is why granting them access was always dangerous. But S3 now sets Object Ownership = Bucket owner enforced on new buckets, which disables ACLs entirely. When ACLs are disabled:
- S3 does not evaluate any ACL at all, so a leftover or accidental “authenticated users” or “public” ACL grant has no effect.
- The bucket owner owns every object automatically, and access is decided only by IAM policies and bucket policies.
What to do in 2026:
- For new buckets: leave ACLs disabled (the default). You do not need to audit the individual ACL grant types below at all — there are no ACLs to misconfigure.
- For older buckets created before April 2023: they may still have ACLs enabled, so the ACL checks below (WRITE, READ, READ_ACP, WRITE_ACP, FULL_CONTROL) still apply. The recommended fix is to migrate them to “Bucket owner enforced” (disable ACLs) after confirming nothing depends on ACLs, then manage access purely through policies.
Treat the remaining ACL items in this list as “history plus a checklist for legacy buckets,” not as day-to-day guidance for new storage.
-
S3 Bucket Public Access Via Policy
S3 bucket policies should not allow all actions for all principals. Ensure that your S3 buckets do not allow public access via bucket policies. This helps you comply with PCI, CBP, GDPR, APRA, MAS, and NIST compliance standards.
-
S3 Bucket Public FULL CONTROL Access
IAM policies should not allow broad list actions on S3 buckets. By ensuring that your AWS S3 buckets are not publicly exposed to the internet, you can protect yourself from misconfigurations. Compliance standards that require you to get rid of such a misconfiguration are PCI, CBP, APRA, MAS, and NIST.
-
S3 Bucket Authenticated Users FULL CONTROL Access
IAM policies should not allow broad list actions on S3 buckets. Ensure that your S3 buckets do not allow FULL_CONTROL access to AWS authenticated users via S3 ACLs. Compliance standards that require you to get rid of such a misconfiguration are PCI, CBP, APRA, MAS, and NIST.
-
S3 Bucket Public READ Access
Allowing public READ access to AWS S3 buckets is a misconfiguration. Make sure that your S3 buckets do not allow public READ access. PCI, GDPR, APRA, MAS, and NIST require you to not have such a misconfiguration.
-
S3 Bucket Authenticated Users READ Access
Ensure S3 buckets do not allow READ access to AWS authenticated users through ACLs. PCI Compliance standards required for this are APRA, MAS, NIST.
-
S3 Bucket Public READ ACP Access
By ensuring your S3 buckets do not allow public READ_ACP access, you can protect your organization from any security misconfiguration. Furthermore, you can be PCI, APRA, MAS, and NIST compliant by getting rid of this misconfiguration.
-
S3 Bucket Authenticated Users READ ACP Access
Similar to the above S3 misconfigurations, ensure S3 buckets do not allow READ_ACP access to AWS authenticated users using ACLs.
-
S3 Bucket Public WRITE_ACP Access
Another very common misconfiguration is allowing public WRITE_ACP access. You should ensure that AWS S3 buckets do not allow public WRITE_ACP access. That way, you can be PCI, APRA, MAS, and NIST compliant.
-
S3 Bucket Authenticated Users WRITE_ACP Access
Similarly, ensure that your AWS S3 buckets do not allow WRITE_ACP access to AWS authenticated users using ACLs.
-
Server-Side Encryption
Ensure that your AWS S3 buckets enforce Server-Side Encryption (SSE). This will help you achieve PCI, SOC2, HIPAA, GDPR, APRA, MAS, and NIST compliance.
2026 update — SSE is already enforced by AWS as a baseline (see the note on Default Encryption above). The remaining, current best practice is to make sure your enforcement covers how data is encrypted, not whether it is. Use a bucket policy that denies
s3:PutObjectunless the request specifies your required encryption (for example,s3:x-amz-server-side-encryptionset toaws:kmswith your key), and consider enabling S3 Bucket Keys to reduce KMS request costs when you move to SSE-KMS at scale. Encryption-in-transit still needs the separate HTTPS-only bucket policy covered earlier in this list — default encryption protects data at rest, not in transit.
2026 addition — your S3 hardening checklist, in priority order
Because AWS now handles several of the original items by default, here is the current, complete checklist so you know exactly what to verify. Do these and you have covered everything above plus the modern gaps:
- Turn on account-level Block Public Access (all four settings). This is your single strongest control and it covers every public-access item on the list at once.
- Keep ACLs disabled (Object Ownership = Bucket owner enforced) on all buckets, and migrate any pre-2023 buckets that still have ACLs enabled. This retires the entire ACL section of this list.
- Control access only through IAM and bucket policies, written least-privilege. Use conditions (
aws:PrincipalOrgID, source VPC endpoint, specific prefixes) to scope access tightly.- Enforce HTTPS and TLS 1.2+ with a bucket policy (deny
aws:SecureTransport=falseand lows3:TlsVersion).- Upgrade encryption to SSE-KMS with a customer-managed key for regulated data; SSE-S3 is already the default baseline.
- Enable versioning plus MFA delete or Object Lock on buckets that must resist ransomware and accidental deletion — a data-durability protection the original list did not mention.
- Run IAM Access Analyzer for S3 continuously; it reports any bucket that policies actually expose outside your account, which is more reliable than manually reading policies.
- Log object activity with CloudTrail data events on sensitive buckets and route findings into GuardDuty and Security Hub.
The theme for 2026: AWS closed the “public by accident” era, so your job shifts to writing precise policies, enforcing strong encryption and transport, and adding durability protections against ransomware — not just flipping public/private switches.
Conclusion
AWS provides many practices, and to ensure proper access and authentication, they should be implemented. The simpler it is to create S3 misconfigurations buckets, the easier it is to make mistakes that can lead to security threats and end up in the exposure of all your data to the internet. By following these simple steps, you can protect your company from any misconfigurations.
Cloudanix provides a recipe for best practices for S3 that helps audit your AWS account for these misconfigurations and more, as part of continuous CSPM with drift detection so a re-opened bucket is caught immediately! We also help you remediate these misconfigurations in an automated way — the same consolidation story as moving from tool sprawl to a single dashboard for ecommerce cloud security. What’s more? You can sign up for a free trial today!
People Also Read
- A Complete List of AWS S3 Misconfigurations
- How to Build Secure AWS S3 Bucket?
- Top 15 Cloud Misconfigurations in 2026 - How to Fix Them?
- Top 13 AWS EC2 Misconfigurations To Avoid in 2022
- 15 Top AWS RDS Misconfigurations To Avoid
- Top 6 AWS IAM Misconfigurations To Avoid in 2022
- How to use CSPM to detect and remediate cloud misconfigurations
- Top 18 Challenges of Cloud Security in 2026
