# Prevent competing S3 writes with explicit object preconditions

> Choose a conditional write that matches whether an object must be new or unchanged.

- Canonical URL: https://update.dsesecurity.com/updates/prevent-competing-s3-writes-with-explicit-object-preconditions/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:13:25+00:00
- Modified: 2026-10-20T18:34:28+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Choose a conditional write that matches whether an object must be new or unchanged.

## Potentially affected

Apply this to supported S3 write operations in applications with concurrent writers, following the specific API requirements.

## DSE recommendation

DSE recommends defining whether a writer is creating a unique key or updating a previously read object.

## Article

Choose a conditional write that matches whether an object must be new or unchanged.

## Source facts

S3 conditional writes accept If-None-Match or If-Match preconditions. If-None-Match checks whether the key already exists; If-Match compares the supplied ETag with the stored object ETag. A mismatched precondition causes the operation to fail instead of silently replacing the object. Versioned buckets evaluate If-None-Match against the current version.

Source: [AWS Documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html).

## Applicability

Apply this to supported S3 write operations in applications with concurrent writers, following the specific API requirements.

## DSE recommendation

DSE recommends defining whether a writer is creating a unique key or updating a previously read object. Make the precondition explicit in the client implementation and treat a conflict as a business decision, not an automatic overwrite. Decide whether to re-read, request human review or abandon the change. Preserve the expected key, ETag and request result in diagnostic records without logging sensitive object contents. Review upload retries so they preserve the original concurrency intent. Define the conflict response in the application contract so support can distinguish an expected rejected update from a storage outage. Require the owner to approve any fallback that retries without the original precondition; that fallback should never be an unnoticed convenience.

## Verification

Proposed verification: have two test writers target one disposable key using controlled preconditions. Confirm the losing request is handled safely and that an intentional update succeeds only with the expected current ETag. Check the chosen API documentation before extending the pattern to other operations.

## Official reference

[AWS Documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html). Reviewed October 20, 2026.

## Primary reference

- Name: AWS Documentation
- Authority: docs.aws.amazon.com
- URL: https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Prevent competing S3 writes with explicit object preconditions,” DSE Security, https://update.dsesecurity.com/updates/prevent-competing-s3-writes-with-explicit-object-preconditions/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.