Harden your S3 Bucket configurations against attacks

The Resilience Duo: Versioning and Object Lock

Versioning is a fundamental feature for any S3 bucket intended for production use. When enabled, S3 never overwrites an object during an update (a PUT request using the same key), nor does it immediately destroy an object when it is deleted (a DELETE request). Instead, it maintains multiple versions, each with a unique ID, and adds a Delete Marker when an object is deleted. This makes it possible to restore data that has been accidentally overwritten.

However, against cyberattacks, versioning alone is not enough. An attacker with administrator privileges can delete every version. This is where Object Lock comes in. Based on the WORM (Write Once, Read Many) model, it prevents an object version from being deleted or modified for a defined period. There are two modes:

Governance Mode: Protects against human error. An administrator with specific permissions (s3:BypassGovernanceRetention) can bypass the lock.

Compliance Mode: Once enabled, nobody, not even the AWS root account, can alter the data before the retention period expires. This provides the strongest protection against ransomware and insider threats.

Encryption: Securing Data at Rest

Today, encrypting data at rest is no longer optional. It is a compliance standard under frameworks such as GDPR and HIPAA. AWS offers several levels of server-side encryption (SSE):

SSE-S3: The default option. Amazon manages the keys end to end, including generation, rotation, and security. Encryption is transparent and free of charge, but you have no direct control over the keys.

SSE-KMS: Uses AWS Key Management Service (KMS). This option provides comprehensive auditing through CloudTrail, allowing you to track who used a key to decrypt a particular file. It also enables separation of duties: a user may have permission to read an S3 bucket, but access will still be denied if they are not authorized to use the KMS key. Be mindful of KMS API request costs.

SSE-C (Customer-Provided Keys): The customer supplies an AES-256 key with the API request. S3 uses it to encrypt the object in memory and then discards it. AWS never stores the key. If you lose it, the data cannot be recovered.

Lifecycle Policies: FinOps Automation

Lifecycle Policies are the engine of your FinOps strategy. They allow you to instruct S3 to perform actions on objects based on their age or prefix. There are two types of actions:

Transition actions: Automatically move an object to a lower-cost storage class after a specified number of days, such as moving data from S3 Standard to S3 Glacier after 90 days.

Expiration actions: Permanently delete an object, or purge previous versions and Delete Markers, after a specified period. This is essential to prevent versioning from driving storage costs through the roof as terabytes of obsolete data accumulate.

Replication (CRR and SRR): Geographic Redundancy

Although S3 natively replicates your data across at least 3 Availability Zones (AZs), each bucket remains tied to a specific AWS region. For disaster recovery (DR) requirements or to reduce latency for users located on another continent, you can configure replication.

CRR (Cross-Region Replication): Asynchronously copies objects to a bucket in a different AWS region, such as from Paris to Tokyo.

SRR (Same-Region Replication): Copies objects to another bucket in the same region, often in a separate AWS account to isolate backups from production environments.

Access Management: The Decline of ACLs

Historically, Access Control Lists (ACLs) were the primary method for managing S3 permissions at the bucket or individual object level. Today, ACLs are considered outdated and potentially risky because they fragment permission visibility.

Best practices, along with AWS defaults since 2023, recommend disabling ACLs through the Object Ownership setting (Bucket owner enforced). Security should instead be managed through bucket policies, which are JSON rules applied to the bucket, and IAM (Identity and Access Management). This centralizes access control and prevents vulnerabilities in which an object uploaded by a third party remains owned by that party.

CORS (Cross-Origin Resource Sharing)

If your frontend application, hosted at app.my-site.com, attempts to upload or download a file directly to or from your bucket (my-bucket.s3.amazonaws.com) through a browser, the browser will block the request for security reasons unless the appropriate cross-origin permissions are configured.

The bucket's CORS configuration explicitly declares which web domains can communicate with your S3 bucket, which methods they can use (GET, PUT, POST), and which headers are permitted. This is essential for serverless architectures and modern web applications.

Auditing and Traceability: Logging and CloudTrail

For security purposes, you need to know who accesses what. S3 provides Server Access Logging, which delivers text files to another bucket containing details of each HTTP request, including the IP address, User-Agent, date, and object.

For deeper integration focused on governance, enabling AWS CloudTrail Data Events records individual S3 API calls, such as GetObject and PutObject, as events that can be analyzed in real time. This provides the foundation for threat detection tools such as DSPM and FIM.

Conclusion

Configuring an S3 bucket involves much more than giving it a name. Every setting, including Versioning, KMS, and Lifecycle Policies, plays a critical role in the three-way balance between security, cost, and performance. Ignoring these settings can expose you to exorbitant bills or, worse, a data breach. Proactively managing your cloud security posture is now essential, so make sure to review your configurations against recommended best practices.