S3 bucket security checklist for SaaS teams
Secure Amazon S3 buckets with account-level public access blocks, least-privilege policies, encryption, access review, safe sharing, and recovery tests.
In this guide
How do you secure an Amazon S3 bucket?
Secure an Amazon S3 bucket by blocking public access unless a reviewed public use case requires it, limiting identity and bucket policies to named actions and resources, protecting data in transit and at rest, and monitoring access and configuration changes. Apply the controls at the highest useful organization or account level as well as to individual buckets. These steps describe Amazon S3; other object-storage services use different controls and defaults.
Enable Block Public Access broadly and verify effective settings
AWS supports Block Public Access controls at organization, account, bucket and access-point levels; the most restrictive applicable settings govern a request. Check all four settings, policy grants, access points and cross-account principals. Do not assume a bucket is private because its name is obscure or a deployment template once set a safe default.
Use bucket and identity policies for specific business access
Grant only the required S3 actions to named roles and resources. Review wildcard principals, wildcard actions, cross-account grants, access-point policies and legacy ACLs. Prefer a single documented access model where possible, and test both an intended read or write and an unauthorized request after changing a policy.
Classify objects and choose storage controls from their sensitivity
Identify customer uploads, exports, backups, logs, public assets and temporary processing files. Apply encryption and key access controls appropriate to each class, use TLS for service connections, and set retention or lifecycle rules with the data owner. Encryption protects confidentiality in some scenarios but does not stop an authorized or public policy from granting access.
| Bucket and data class | Public and cross-account access | Allowed roles and actions | Encryption, logs and retention | Owner and verified test |
|---|---|---|---|---|
| Customer uploads | ||||
| Backups or exports | ||||
| Public product assets |
What should an S3 bucket security audit check?
Find exposure through every access path
Review account and organization public-access settings, bucket policies, ACLs if enabled, access points, website configuration, replication targets and cross-account role trust. Confirm which objects can be read, listed, overwritten or deleted. An intentional public asset should have the minimum read-only access and a separate path from private customer data.
Protect uploads and temporary download links
For pre-signed URLs, restrict the object and operation, use a short useful expiry, and avoid leaking the URL through logs, analytics, referrers or support tickets. Validate the caller before issuing a link and do not treat possession of a URL as proof of identity beyond its scoped, time-limited bearer access. Review the application flow as well as the bucket policy.
Enable evidence and recovery controls appropriate to the data
Review access logging or provider-supported data events, configuration history, versioning, replication and backup protections. Limit who can disable logging or remove versions, and test recovery for accidental deletion or a compromised administrator. These controls have different cost and retention tradeoffs, so align them with recovery objectives and legal obligations.
How should teams fix an exposed S3 bucket?
Contain public or unintended access and preserve evidence
Confirm the affected bucket, object scope and policy path, then block unintended access using the narrowest reliable control that contains the exposure. Preserve relevant configuration and access records, determine whether sensitive objects were retrieved, and follow the incident response and notification process that applies to the organization and data.
Remove the source of exposure and verify effective access
Correct the IaC, account policy, bucket policy, ACL or access point that created the path. Check for public grants in sibling buckets and other accounts, test from an unauthenticated context, and confirm intended application roles still function. AWS notes that higher-level Block Public Access settings can override lower-level policies, so validate the effective result.
Prevent the same mistake in provisioning and operations
Set safe defaults in reusable infrastructure modules, block or alert on risky public-policy changes, review access grants periodically and assign every bucket an owner. Keep an explicit approval path for public product content and recheck it after a new CDN, domain, migration or data-use change.
S3 bucket security FAQs
Can an S3 bucket be public for a website and still be safe?
Public website content can be served intentionally, but keep access read-only and limited to the intended objects. AWS describes using CloudFront while keeping bucket access blocked from the public internet as one option. Do not make a customer upload or backup bucket public to serve static assets.
Does enabling encryption prevent a bucket data leak?
No. Encryption at rest is an important control, but authorized roles, public policies, application links and key permissions still determine who can access readable data. Review the whole access path and confirm the encryption configuration meets the service's requirements.
Are pre-signed URLs private credentials?
Treat them as bearer credentials: anyone who obtains a valid link may be able to perform its scoped action until it expires or becomes unusable. Limit scope and duration, protect logs and messages, and re-check user authorization before issuing one.
Do these S3 settings apply to every cloud storage service?
No. This guide uses Amazon S3 documentation. Map the security goals to the controls, policy evaluation order and defaults of the object-storage provider you actually use, then test effective access rather than copying S3 settings verbatim.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- Amazon S3: Security Best PracticesAmazon Web Services
- Amazon S3: Blocking Public Access to StorageAmazon Web Services
- OWASP Infrastructure as Code Security Cheat SheetOWASP Foundation