How to Use ETags in ASP.NET Core to Prevent Users from Overwriting Each Other’s Changes

Imagine two users are editing the same customer record in an application. Both open the record at the same time. The first user changes the customer's phone number and saves it. A few minutes later, the second user saves an older copy of the record.

The second save may overwrite the first user's changes without showing any warning.

This problem is common in applications where multiple users can update the same data. In ASP.NET Core, you can use ETags and optimistic concurrency control to prevent these accidental overwrites.

An ETag helps the server identify a particular version of a resource. When a client sends an update, it can tell the server which version it originally received. If the data has changed since then, the server can reject the update instead of silently replacing someone else's work.

In this article, we will see how ETags work, how to use them in an ASP.NET Core API, and how to combine them with Entity Framework Core to handle concurrent updates safely.

What Is an ETag?

An ETag, or entity tag, is a value that identifies a particular version of a resource.

For example, an API might return a product like this:

HTTP/1.1 200 OK
ETag: "product-version-1"
Content-Type: application/json

The response body contains the product information. The ETag identifies the version of that information.

If the product changes, its ETag should also change. A client can then send the ETag back when updating the product.

ETags are commonly used for two purposes:

Caching: Helps clients determine whether a cached response is still valid.
Concurrency control: Helps prevent updates based on outdated data.

Here, we will focus on concurrency control.

How ETags Prevent Conflicting Updates

Suppose two users open the same product.

Both users receive the product with ETag "version-1".
User A changes the price and saves the product.
The server updates the product and its version.
User B tries to save changes using the old ETag.
The server detects that the version has changed and rejects User B's update.

The server can return 412 Precondition Failed because the condition supplied with the request is no longer valid.

The important point is that the server does not blindly accept the second update. The client can reload the latest data and decide how to handle the conflict.

Step 1: Create a Product Model with a Version Column

We will use Entity Framework Core with SQL Server. SQL Server supports a rowversion column that changes automatically when a row is updated.

This makes it useful for detecting concurrent changes.

Create a product model:

using System.ComponentModel.DataAnnotations;

public class Product
{
    public int Id { get; set; }

    public string Name { get; set; } = string.Empty;

    public decimal Price { get; set; }

    [Timestamp]
    public byte[] RowVersion { get; set; } = [];
}

The [Timestamp] attribute tells Entity Framework Core to treat RowVersion as a concurrency token.

When SQL Server updates the row, it generates a new rowversion value. EF Core uses the original value when checking whether the update is still valid.

For SQL Server, the corresponding database column should be configured as rowversion. EF Core migrations can create this column from the model configuration.

Do not use the rowversion value as a timestamp that represents the date and time of an update. It is a version marker, not a clock.

Step 2: Return an ETag When Reading a Product

When the client requests a product, return its data along with an ETag.

[HttpGet("{id:int}")]
public async Task<IActionResult> GetProduct(int id)
{
    var product = await _context.Products
        .AsNoTracking()
        .FirstOrDefaultAsync(p => p.Id == id);

    if (product == null)
    {
        return NotFound();
    }

    string etag = Convert.ToBase64String(
        product.RowVersion);

    Response.Headers.ETag = $"\"{etag}\"";

    return Ok(new
    {
        product.Id,
        product.Name,
        product.Price
    });
}

This endpoint reads the product and creates an ETag from its rowversion.

The response might look like this:

HTTP/1.1 200 OK
ETag: "AAAAAAAAB9E="
Content-Type: application/json

The actual ETag value will depend on the database rowversion.

The client should save this ETag along with the product data. It will need the same value when sending an update.

Step 3: Require the ETag When Updating a Product

When a client updates a product, it should send the ETag it received earlier through the If-Match request header.

For example:

PUT /api/products/10
If-Match: "AAAAAAAAB9E="
Content-Type: application/json

The server can compare this value with the latest version of the product.

The following example shows the core update logic:

[HttpPut("{id:int}")]
public async Task<IActionResult> UpdateProduct(
    int id,
    UpdateProductRequest request)
{
    string ifMatch = Request.Headers.IfMatch.ToString();

    if (string.IsNullOrWhiteSpace(ifMatch))
    {
        return StatusCode(
            StatusCodes.Status428PreconditionRequired,
            "The If-Match header is required.");
    }

    var product = await _context.Products
        .FirstOrDefaultAsync(p => p.Id == id);

    if (product == null)
    {
        return NotFound();
    }

    string currentETag =
        $"\"{Convert.ToBase64String(product.RowVersion)}\"";

    if (!string.Equals(
        ifMatch,
        currentETag,
        StringComparison.Ordinal))
    {
        return StatusCode(
            StatusCodes.Status412PreconditionFailed,
            "The product has changed. Reload it before updating.");
    }

    product.Name = request.Name;
    product.Price = request.Price;

    try
    {
        await _context.SaveChangesAsync();
    }
    catch (DbUpdateConcurrencyException)
    {
        return StatusCode(
            StatusCodes.Status412PreconditionFailed,
            "Another user updated the product. Reload and try again.");
    }

    return NoContent();
}

public class UpdateProductRequest
{
    public string Name { get; set; } = string.Empty;

    public decimal Price { get; set; }
}

This example assumes _context is an injected EF Core database context and the controller has the necessary ASP.NET Core and EF Core namespaces.

There are three important parts of this implementation.

First, the endpoint requires an If-Match header. The server returns 428 Precondition Required if the client does not provide one.

Second, the endpoint compares the supplied ETag with the version currently stored in the database. If they differ, the server returns 412 Precondition Failed.

Third, the endpoint catches DbUpdateConcurrencyException. This check is essential because another user might update the product after the ETag comparison but before the current request saves its changes.

The database concurrency check closes this race condition. Comparing ETags in application code alone is not enough to guarantee safe updates.

This example supports one exact ETag per request. A complete implementation should also handle the HTTP If-Match rules for wildcard values and lists of entity tags, or use a tested helper that implements those rules.

Step 4: Configure Entity Framework Core Correctly

The database must enforce the rowversion check. For SQL Server, EF Core can generate an update that includes the original rowversion in its condition.

Conceptually, the update behaves like this:

UPDATE Products
SET Name = @name,
    Price = @price
WHERE Id = @id
  AND RowVersion = @originalRowVersion;

If another request has already changed the row, the original rowversion no longer matches. The update affects no row, and EF Core reports a concurrency exception.

This is why the [Timestamp] attribute matters. Without a correctly configured concurrency token, the database update might overwrite a newer version even if the application initially checked the ETag.

If you use PostgreSQL, MySQL, or another database, the concurrency mechanism may differ. Configure and test the appropriate concurrency token for that provider.

What Should the Client Do When It Receives a 412 Response?

A client should not automatically resend the same update with the old ETag. The data has already changed, so repeating the same request will not solve the conflict.

A better approach is:

Display a message explaining that the record has changed.
Fetch the latest version of the record.
Compare the current data with the user's pending changes.
Let the user review or merge the changes when necessary.
Submit the update again using the latest ETag.

For simple forms, reloading the latest record may be sufficient. For complex editing workflows, you may need a conflict-resolution screen that shows which fields changed.

ETags vs. Other Concurrency Approaches

Approach	How it works	Best suited for
ETags with `If-Match`	The client sends the version it expects	HTTP APIs and resource updates
EF Core concurrency tokens	The database update checks the original version	Database-backed applications
Pessimistic locking	Locks prevent competing operations from proceeding concurrently	Specific workflows that require locking
Last-write-wins	The latest accepted update replaces earlier values	Applications where overwriting is acceptable

ETags and EF Core concurrency tokens work well together. The ETag communicates the expected version through HTTP, while the database concurrency token protects the actual update.

Pessimistic locking can be useful for specialized workflows, but it introduces locking, timeout, and contention concerns. It is often unnecessary for ordinary web forms.

Common Mistakes to Avoid

Checking the ETag but Ignoring Database Concurrency

A version can change between the initial comparison and the database save. Always use a database concurrency token or another atomic conditional-update mechanism.

Returning a Generic Server Error

A concurrency conflict is an expected condition, not necessarily an application failure. Return an appropriate response such as 412 Precondition Failed when the If-Match condition is no longer satisfied.

Accepting Updates Without a Version Check

If every update ignores the ETag, the API cannot protect clients from overwriting newer data. Make the version requirement part of the endpoint's contract.

Reusing an Old ETag

After a successful update, the client should obtain the latest ETag, either from the next GET request or from the update response if the API returns one.

Assuming Every Database Uses SQL Server Rowversion

The [Timestamp] example is intended for SQL Server. Other database providers may require different concurrency-token configurations.

Advantages and Disadvantages

Advantages

Prevents many accidental overwrites when users edit the same record.
Works naturally with HTTP request and response headers.
Allows the server to reject outdated updates without locking records throughout the editing process.
Works with EF Core optimistic concurrency when configured correctly.
Helps clients build clear conflict-resolution workflows.

Disadvantages

Requires clients to store and send the correct ETag.
Adds version-checking and conflict-handling logic.
Does not automatically merge changes from different users.
Requires database-level concurrency protection to avoid race conditions.
Needs additional care when handling HTTP If-Match syntax and non-SQL Server databases.

Best Practices for Production Applications

Use a strong ETag for updates that require exact version matching.
Require If-Match on endpoints where overwriting newer data would be harmful.
Configure a database concurrency token and handle concurrency exceptions.
Return clear error messages without exposing internal database details.
Test two concurrent updates to verify that only one succeeds when both use the same original version.
Return or expose the latest ETag after successful updates so clients can continue editing safely.
Apply authorization checks before allowing users to update a resource.
Remember that ETags prevent stale updates; they do not replace input validation, authentication, or authorization.

Summary

ETags provide a straightforward way to prevent users from accidentally overwriting each other's changes in ASP.NET Core applications. The server returns an ETag when a client reads a resource, and the client sends that value back through the If-Match header when updating it.

If the resource has changed, the server rejects the outdated update instead of silently accepting it.

For reliable results, combine ETags with EF Core concurrency tokens or an equivalent atomic database check. This protects the application not only from stale client data but also from updates that happen between the version check and the database save.