Thomas Tartière's blog - django

Understanding Cookies and CSRF with Django

2025-10-17T15:49:00-07:00

Intro

Over the past few weeks, as part of our annual SOC II audit and penetration test, I've been reviewing the security of our authentication workflow. I wrote this article to clarify how some concepts work in our products for the developers on my team, and thought this could be useful to others.

What Cookies Actually Are
How Django Session Authentication Works
What CSRF Attacks Are (and Why We Care)
How Django's CSRF Protection Stops This
How Cookie Attributes Keep Things Safe
- HttpOnly
- Secure
- Path
- SameSite
- Expires / Max-Age

1. What Cookies Actually Are

Cookies are small pieces of data that your browser stores for a website. Every time your browser sends a request to that site, it automatically includes any cookies that belong to it.

They’re what let websites “remember” things — like that you’re logged in, what’s in your cart, or what theme you picked.

Each cookie has a few properties that tell the browser how and when to send it, like:

its name and value,
which domain and path it applies to,
how long it lasts,
and a few security flags like HttpOnly, Secure, and SameSite.

Without cookies, every request would look like it’s coming from a brand-new visitor — which is why they’re so central to authentication.

One important fact to be clear about: Cookies are only sent with requests to the same domain that issued them. If you log in to app.mydomain.com, your browser will only send that cookie back to app.mydomain.com — not to any other site. This is the foundation of how browsers isolate data between websites.

When you are on a given website, you can open the dev tools > Storage and see the list of cookies:

2. How Django Session Authentication Works

Django’s default way to handle login sessions is called session authentication. Here’s how it works, step by step:

When a user logs in, Django creates a "session" on the server. Where the session is stored is controlled by the SESSION_ENGINE settings, and for our products we use Redis, but it's also possible to store them in the database or in a file.
Django gives the browser a cookie (usually called sessionid).
The cookie doesn’t contain any personal data — just a random session key.
On each request to the app domain name, the browser automatically includes that cookie, and Django looks up which user it belongs to.

So when you see request.user in Django, that’s the session system doing its work behind the scenes.

The key idea is that the cookie is just a pointer — all the real data stays safely on the server.

3. What CSRF Attacks Are (and Why We Care)

Now that we know cookies are sent automatically, let’s talk about a common attack that abuses this: Cross-Site Request Forgery (CSRF).

Imagine this:

You’re logged into your app and your browser has your sessionid cookie.
While still logged in, you visit a shady website called evil.com.
That site quietly includes a hidden form that submits a POST request to https://app.mydomain.com/api/delete_account/.
When your browser submits the form, it automatically includes your sessionid cookie — because it still belongs to app.mydomain.com.
From Django’s perspective, it looks like you clicked “delete my account.”

That’s a CSRF attack — the attacker “forged” a request using your browser and your valid session cookie.

Without protection, a site could trick your browser into performing any action you’re authorized to do.

4. How Django’s CSRF Protection Stops This

Django solves this problem using a CSRF token — a secret value that helps verify that every state-changing request truly came from your own site and not from somewhere else.

Let’s revisit the example from above, but this time with Django’s CSRF protection enabled.

Step-by-Step Example

When you log in to https://app.mydomain.com, Django sets two cookies:
sessionid: used to identify your login session.
csrftoken: a random secret token used for CSRF protection.
When Django serves a page that contains a form, it embeds the CSRF token in that page. For example, in a Django template, you'll often see:

<form method="POST">
    {% csrf_token %}
    ...
</form>

This template tag inserts a hidden input like:

<input type="hidden" name="csrfmiddlewaretoken" value="abc123...">

When you submit the form, both the cookie and the hidden token are sent back to the server.
The browser automatically sends the csrftoken cookie.
The form submits the hidden token value in the POST body.
Django's CSRF middleware checks that the token in the form matches the one in the cookie. If they match, Django knows the request came from a genuine page served by app.mydomain.com.
Now imagine the malicious site again (evil.com). It tries to submit the same POST request to https://app.mydomain.com/api/delete_account/, but:
- It cannot read your CSRF cookie (browsers don’t let one site read another site’s cookies).
- It cannot include the correct CSRF token in the request.
As a result, Django sees a missing or invalid token and immediately rejects the request with a 403 Forbidden.

So even though your browser still sends the sessionid cookie automatically, Django’s CSRF middleware stops the request from being accepted — because the secret CSRF token doesn’t match.

Why This Works So Well

The CSRF cookie itself is harmless: it doesn’t grant access to anything; it just stores a random value.
The protection relies on a double submit principle: Django expects both a cookie and a matching token from the same origin.
Since attackers can’t read cookies from another domain, they can’t guess or replay a valid CSRF token.

This small extra step effectively blocks one of the most common web vulnerabilities — all while being invisible to the user.

5. How Cookie Attributes Keep Things Safe

Below I break down the common cookie attributes we use and show, for each one, a short example of the kind of attack it helps mitigate.

HttpOnly

What it does

Prevents client-side JavaScript from reading the cookie value.

Why we use it

Set HttpOnly on cookies that don’t need to be read by JS (for us that’s typically sessionid). This reduces the damage if an attacker can run JavaScript on the page (XSS).

Attack it mitigates — XSS token theft example

If an attacker finds an XSS hole and injects <script> that tries document.cookie, any cookie with HttpOnly won’t be returned to their script. Without HttpOnly, a script could steal sessionid and send it to the attacker, allowing session hijacking.

Notes

CSRF tokens must be readable by JS when the front-end needs to include them in AJAX requests, so csrftoken is often not set to HttpOnly.

Secure

What it does

Instructs the browser to send the cookie only over HTTPS connections.

Why we use it

Protects cookie values from being exposed over plaintext HTTP, which can be sniffed on the network.

Attack it mitigates — network eavesdropping / man-in-the-middle example

If someone is intercepting traffic on a public Wi-Fi, cookies marked Secure won’t be sent over plain HTTP requests the attacker can sniff. Without Secure, an attacker could capture the cookie and reuse it to impersonate the user.

Notes

Always enable Secure in production. Combining Secure with SameSite=None is required by modern browsers for cross-site cookies.

Path

What it does

Limits which URL paths on the domain the browser will include the cookie with.

Why we use it

Narrowing the Path reduces exposure — for example, an admin session cookie could be scoped to /admin/.

Attack it mitigates — limited-scope misused cookie example

If an attacker can induce a request to a lower-risk endpoint (e.g., /public/), scoping an admin cookie to /admin/ prevents that request from including the admin cookie. This lowers the chance of accidental exposure and reduces the blast radius if some endpoint is misused.

Notes

Be conservative: overly broad Path values increase where the cookie is sent; overly narrow ones can break legitimate flows. Use it when you can segment responsibilities by path.

In our current review of the LEAN authentication flow, I found out that we can use the path attribute to make sure that the refresh token is only sent to the refresh endpoint and not sent otherwise.

SameSite

What it does

Controls whether the browser includes the cookie on cross-site requests.

Why we use it

A key defense against CSRF. It’s the browser-level control that reduces cookies being sent automatically on cross-site requests.

A cross-site request is a http request from one domain to another.

For instance, consider a page hosted on badguy.com that includes a form to submit a POST request to app.mydomain.com. If SameSite is set to "None", the session and CSRF cookies will be sent along with the request when the form is submitted, which is obviously not good. To prevent this, the default value for the SameSite attribute is "Lax", which would prevent this scenario.

There are 3 possible values for the SameSite attribute (more details here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value):

With Strict, the cookies are only sent with requests to the domain that issued them. This is great, except in one scenario: imagine that you are currently logged into our app and you receive an alert email with a link to click on. This is a cross-origin request, so when you click on it, the browser won't include your existing session cookie and the server will redirect you to the login page.

In this scenario, this is a "safe" request (GET) only used for navigation, and that's what the Lax value for the SameSite attribute handles: it prevents including the cookies in cross-origin requests except if they are for top-level navigation. With Lax, normal link navigation will send the cookies, providing a good user experience, but hidden POSTs or background requests from evil.com will not send the cookie.

Notes

Lax is a good balance for sessionid — it preserves bookmark/link behavior while blocking many CSRF vectors. Strict is safer but can break expected cross-site navigation. None allows all cross-site sends and should be avoided unless necessary and secured with Secure.

Expires / Max-Age

What it does

Controls how long the cookie lives (session cookie vs persistent cookie).

Why we use it

Shorter lifetimes reduce the window of opportunity for attackers if a cookie is leaked; persistent cookies improve UX but increase risk.

Attack it mitigates — long-lived stolen cookie example

If a persistent cookie is stolen (e.g., via backup leaks), an attacker can reuse it for as long as it’s valid. By setting reasonable expiry times and using refresh mechanisms server-side (e.g., rotating session keys), we reduce exposure.

Notes

For very sensitive sessions, prefer shorter max-age and consider requiring re-authentication for sensitive actions.

Versioned Static Assets in Django with Docker

2024-12-31T16:34:00-08:00

Introduction
The Problem with Static Files in Django Deployments
2.1 Option 1: Run collectstatic During Deployment
2.2 Option 2: Run collectstatic During Docker Build
A Versioned Approach to Static Assets
3.1 Overview
3.2 Implementation Example with django-storages
Conclusion

Introduction

When deploying Django applications with Docker, managing static files efficiently and safely is a common challenge. The need to use the collectstatic command—which aggregates and processes all static files —complicates deployments, especially in multi-environment setups like staging and production. This article explores various approaches to handling static files and introduces a versioning strategy for more reliable deployments.

The Problem with Static Files in Django Deployments

The collectstatic command is essential in Django to gather static files from various apps and prepare them for serving via a CDN from a storage service like AWS S3 or Azure Blob Storage. However, this step introduces deployment complexities:

Option 1: Run `collectstatic` During Deployment

One approach is to avoid running collectstatic during the Docker build process and instead execute it during deployment for each environment (e.g., staging or production).

Problems:

Error Detection Delay: Issues with static files are only discovered at deployment time, making debugging more challenging.
Discrepancies Between Environments: collectstatic often performs additional optimizations like file compression (e.g., via django-compressor). Running it multiple times for different environments increases the risk of inconsistencies.
Rollback Challenges: Rolling back a deployment requires re-running collectstatic for the previous version. This can be time-consuming, taking several minutes or even tens of minutes, and complicates rapid recovery.

Option 2: Run `collectstatic` During Docker Build

Another approach is to execute collectstatic as part of the Docker build process.

Challenges:

Risk of Overwriting Files: If the new static files are pushed to the same storage location used by the production environment, there is a risk of overwriting or corrupting existing files.
Increased Build Time: Running collectstatic during the build process increases the time required to build the Docker image.

A Versioned Approach to Static Assets

Overview

A more robust solution is to incorporate a versioning strategy during the Docker build process. By using a RELEASE_VERSION build argument—following semantic versioning—we can organize static files by version in the storage account. Here’s how it works:

Set a Version Identifier: During the Docker build, pass a RELEASE_VERSION argument to identify the application version (e.g., v1.2.3).
Organize Static Files by Version: Modify the collectstatic process to store files in a folder named after the version (e.g., static/v1.2.3/).
Ensure Environment Independence: Use a single storage account for all environments. Static files are an integral part of the application and should not depend on a specific environment. Since static files are versioned, there is no risk of interference between environments..

This strategy provides several benefits:

Easy Rollbacks: To roll back, simply configure the application to use the static files from the previous version. No re-running of collectstatic is required.
Environment Consistency: All environments use the same set of static files for a given version, eliminating discrepancies.
Preservation of Static Files: Files from different versions are stored separately, avoiding overwrites and corruption. This approach also facilitates concurrent deployments and aligns well with blue-green deployment strategies, as each version's static files remain isolated and accessible without interference. When deploying a new version in a cluster, containers are typically updated incrementally rather than all at once. With this method, each running version maintains access to its specific static files until all containers are successfully updated to the latest version.

Implementation Example with `django-storages`

django-storages is a typical package that simplifies using remote storage accounts in a Django application (see documentation at https://django-storages.readthedocs.io).

Implementing the approach described in the previous section requires to modify the default behaviour of django-storages. Below is an implementation of the versioned approach using Azure Blob Storage. A similar approach can be used with AWS S3 or other storage services.

We first need to define a custom storage class to prefix each static filepath with the current app version, as shown below:

# config/storages.py
import os

from django.conf import settings

from storages.backends.azure_storage import AzureStorage


class StaticAzureStorage(AzureStorage):
    """Define separate azure storage
    container for public files.
    """
    account_name = settings.AZURE_ACCOUNT_NAME_STATIC
    account_key = settings.AZURE_ACCOUNT_KEY_STATIC
    azure_container = settings.AZURE_CONTAINER_STATIC
    expiration_secs = None

    def _get_valid_path(self, name: str) -> str:
        """Concatenate the app version to the filename to make
        sure all files are stored within a versioned folder

        Args:
            name (str): filename

        Returns:
            str: filepath that includes the app version
        """
        version = settings.RELEASE_VERSION
        name = os.path.join(version, name)
        return super()._get_valid_path(name)

We can then configure the Django settings to use this custom storage class:

# config/settings/base.py

# -------------------------------
# Azure Storage Configuration
# ---------------------------------

# Azure blob storage for static files
AZURE_ACCOUNT_KEY_STATIC = env.str("AZURE_STORAGE_ACCOUNT_KEY_STATIC", default=None)
AZURE_ACCOUNT_NAME_STATIC = env.str("AZURE_STORAGE_ACCOUNT_NAME_STATIC", default=None)
AZURE_CONTAINER_STATIC = env.str(
    "AZURE_STORAGE_CONTAINER_STATIC", default="lean-api-static"
)

AZURE_STORAGE_FOR_STATIC_ENABLED = AZURE_ACCOUNT_NAME_STATIC and AZURE_CONTAINER_STATIC
AZURE_CUSTOM_DOMAIN_STATIC = (
    f"{AZURE_ACCOUNT_NAME_STATIC}.blob.core.windows.net"
    if AZURE_ACCOUNT_NAME_STATIC
    else None
)

# ---------------------------------------------------------------------------
# Default storage options
# ---------------------------------------------------------------------------
STORAGES = {
    # See defaults in, https://docs.djangoproject.com/en/4.2/ref/settings/#storages
    "default": {
        "BACKEND": "django.core.files.storage.FileSystemStorage",
    },
    "staticfiles": {
        "BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage",
    },
}

# ---------------------------------------------------------------------------
# STATIC files
# ---------------------------------------------------------------------------

STATIC_ROOT = os.path.join(BASE_DIR, "static")
STATIC_HOST = env("DJANGO_STATIC_HOST", default="")
STATIC_URL = STATIC_HOST + "/static/"

# https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#staticfiles-finders
STATICFILES_FINDERS = [
    "django.contrib.staticfiles.finders.FileSystemFinder",
    "django.contrib.staticfiles.finders.AppDirectoriesFinder",
]

# https://docs.djangoproject.com/en/4.0/ref/settings/#prefixes-optional
STATICFILES_DIRS = [
    # Specify static files in <root>/templates/static directory to be collected by collectstatic command
    ("templates", "templates/static"),
]

if AZURE_CUSTOM_DOMAIN_STATIC:
    # Azure Blob Storage
    # ---------------------------------------------------------------------------
    STORAGES["staticfiles"]["BACKEND"] = "config.storages.StaticAzureStorage"

    if STATIC_HOST:
        STATIC_URL = f"https://{STATIC_HOST}/{AZURE_CONTAINER_STATIC}/"
    else:
        # if a CDN host is not provided, then we set the static url to the
        # Blob storage container url
        STATIC_URL = f"https://{AZURE_CUSTOM_DOMAIN_STATIC}/{AZURE_CONTAINER_STATIC}/"

The last step is to modify our Dockerfile to run collecstatic command during build:

# Dockerfile
# ...

# define the build arguments
ARG AZURE_STORAGE_ACCOUNT_NAME_STATIC="" \
    AZURE_STORAGE_CONTAINER_STATIC="" \
    RELEASE_VERSION

# save build-arguments as environment variables in the image
ENV DJANGO_SETTINGS_MODULE=config.settings.production \
    AZURE_STORAGE_ACCOUNT_NAME_STATIC=$AZURE_STORAGE_ACCOUNT_NAME_STATIC \
    AZURE_STORAGE_CONTAINER_STATIC=$AZURE_STORAGE_CONTAINER_STATIC \
    RELEASE_VERSION=$RELEASE_VERSION

# Collect static files
# if it is a production build, use the azure storage key passed as a
# build secret to store all the static files in the azure storage account.
# To use this, run docker build --secret id=azure_storage_account_key_static,env=AZURE_STORAGE_ACCOUNT_KEY_STATIC ....
RUN --mount=type=secret,id=azure_storage_account_key_static,required AZURE_STORAGE_ACCOUNT_KEY_STATIC=$(cat /run/secrets/azure_storage_account_key_static) \
    python manage.py collectstatic --no-input

Sending static files to the storage account in Azure requires the name of the container, the name of the storage account and an account key. This last parameter is a secret and shouldn't be saved as an environment variable in the image. To prevent this, it is passed as a build secret. A build secret is temporarily mount inside the build container, for the duration of the build instruction.

Docker build command

When building the docker image, we now need to provide the release version, storage account name and container name as build argument, and the storage account key as a build secret:

VERSION=v1.2.3

# build the image
docker build -t your-app:$(RELEASE_VERSION) \
  -f Dockerfile \
  --build-arg RELEASE_VERSION=$(RELEASE_VERSION) \
  --build-arg AZURE_STORAGE_ACCOUNT_NAME_STATIC=<name of the storage account> \
  --build-arg AZURE_STORAGE_CONTAINER_STATIC=<name of the container> \
  --secret id=azure_storage_account_key_static,env=<private key> \
   .

# push the image to the registry
docker push your-app:$VERSION

Key Considerations

Storage Costs: Versioning static files increases storage usage. Without the approach described here, it's very hard to free space as the static files accumulate in the same folder. With this approach, it's easy to delete the folder matching old versions of the application that we don't intend to use in production anymore.
Environment Setup: Since the Docker image contains the reference to the storage account as an environment variable, the Docker image can be deployed anywhere easily, ensuring all environments fetch static files from the correct version folder.

Conclusion

By adopting a versioning strategy for static assets, you can address key challenges in Django deployments effectively. This approach ensures seamless rollbacks, maintains environment consistency, and avoids file overwrites or corruption. Additionally, because the Docker image includes environment-independent references to the storage account, deployment is streamlined across environments. While this strategy requires some upfront configuration and storage management, its reliability and scalability make it a worthwhile investment for production-grade applications.

Avoiding Lost Updates in Web Applications

2024-12-18T13:49:00-08:00

Introduction
The Problem: Lost Updates with a Django API Endpoint
2.1 Demo App
2.2 Simulating Concurrent Requests
Understanding Read Committed Isolation Level
3.1 What is Read Committed?
3.2 What it Doesn't Guarantee
Solutions to Avoid Lost Updates
4.1 Solution 1: Atomic Write with F() Expressions
4.2 Solution 2: Change Isolation Level to Serializable
4.3 Solution 3: Use select_for_update() for Complex Queries
Conclusion
References and Further Readings

Introduction

Ignoring concepts like proper database transactions and handling race conditions might seem harmless at first, but it’s a recipe for concurrency bugs that are incredibly hard to debug. These bugs have a knack for showing up at the worst possible time—usually once your app has scaled—leading to massive headaches and sleepless nights. In this post, we’ll explore how to prevent these issues in Django, saving your future self from countless hours of frustration.

Relational databases like PostgreSQL offer various levels of transaction isolation to manage concurrent data access. The most common (and often default settings) is Read Committed, which can lead to lost updates in certain scenarios. This tutorial demonstrates the problem and explores solutions using a Django application, but the problem and solutions are relevant for any framework.

We'll:

Define a basic Django app that increments a counter through an endpoint.
Explain the Read Committed isolation level and its limitations.
Provide solutions:
1. Using atomic write operations with Django's F expressions.
2. Switching to Serializable isolation.
3. Leveraging select_for_update() for complex cases.

The demo app and code samples can be found in this repository: https://github.com/tartieret/django-isolation-levels

1. The Problem: Lost Updates with a Django API Endpoint

Demo app

Imagine a simple Django app where an endpoint increments a counter stored in a PostgreSQL database. Here's the basic implementation:

# models.py
from django.db import models

class Counter(models.Model):
    name = models.CharField(max_length=100, unique=True)
    value = models.PositiveIntegerField(default=0)

# views.py
import time

from django.http import JsonResponse
from django.db import transaction

from .models import Counter

@transaction.atomic
def increment_counter(request, name):
    """This endpoint receives a GET request such as:
    GET http://localhost:8000/counters/increment/myCounter/
    """
    # Retrieve the counter object
    counter = Counter.objects.get(name=name)

    # Simulate a slow API endpoint
    time.sleep(5)

    # Increment and save
    counter.value += 1
    counter.save()

    # Return a JSON response
    return JsonResponse({"name": name, "value": counter.value})

# urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('increment/<str:name>/', views.increment_counter, name='increment_counter'),
]

Here, when the /counters/increment/<name>/ endpoint is called, it retrieves the counter, increments its value, and saves the updated value.Simulating Concurrent Requests

Using the admin portal, let's create a first counter called "test," with initial value of zero:

Simulating Concurrent Requests

We'll now try to send multiple requests to this endpoint in parallel, as an example of what could happen in real life with multiple concurrent users.

To simulate concurrent requests, we can use the concurrent.futures module in Python to send multiple requests in parallel and build the following run_test.py script:

import requests
from concurrent.futures import ThreadPoolExecutor

URL = "http://localhost:8000/counters/increment/test/"

# Function to send a request
def send_request(url):
    response = requests.get(url)
    print(response.json())

# Send 10 requests in parallel
with ThreadPoolExecutor(max_workers=10) as executor:
    futures = [executor.submit(send_request, URL) for _ in range(10)]

print("All requests completed.")

The script above will send ten concurrent requests to our local web server. Intuitively, we would expect the final counter value to be equal to 10. Let's run it!

What's happening? Each concurrent request returns a value of 1 for the counter!!!

Checking the counter in the admin portal, we can verify that the final value is indeed 1, in spite of having processed ten requests to increment it.

The schematic below gives a visual representation of what happened:

The server receives request #1 (in blue), and a zero value is retrieved from the database. It takes a while for the transaction to finish and for the counter = counter + 1 operation to be committed.
In the meantime, request #2 (in red) is received and processed similarly. It starts by reading the counter's current value (zero) in the database and incrementing it by one.
...
Similarly, request #n (in green) is received, reads the value of the counter, and commits a new value of 0 + 1 = 1 to the database after about 5 seconds.

This problem is known as a lost update. Another transaction overwrites changes made by one transaction without the latter being aware of the former's change.

This typically happens when two or more transactions access the same data and then perform an update based on what was read. If there is no locking mechanism in place, we are losing some of the updates as the defaut isolation level (read committed) only guarantees that each transaction is based on a value that was previously committed.

2. Understanding Read Committed Isolation Level

What is Read Committed?

Read Committed is the default isolation level in PostgreSQL, Microsoft SQL server, and other relational databases. It ensures that:

When reading from the database, we only see data that has been committed (no dirty reads).
When writing to the database, we only overwrite data that has been committed (no dirty writes)

What it Doesn't Guarantee

Read Committed does not prevent non-repeatable reads or lost updates:

Non-repeatable reads: The same query can return different results within a transaction.
Lost updates: Two transactions can overwrite each other's updates because they operate on the same snapshot of the data.

In our example, all transactions read the same value (0), increment it, and overwrite each other's result.

A full description of transaction guarantees and isolation levels is outside the scope of the present article, but I refer you to the following resources for more information:

PostgreSQL transaction isolation: https://www.postgresql.org/docs/current/transaction-iso.html
Designing Data-Intensive Applications, by Martin Kleppman (Chapter 7): https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/

3. Solutions to Avoid Lost Updates

Solution 1: Atomic Write with `F()` Expressions

The trivial example given above can be avoided by using an atomic update operation, which removes the need to read-modify-write. For example, the counter update can be performed using the following SQL query:

UPDATE counters SET value = value + 1 WHERE name='test';

Django's F() Expressions allow you to perform atomic operations at the database level without retrieving and updating the value in Python, which avoids race conditions.

Using this approach, we can add a new endpoint to increment our counter:

# ...
from django.db.models import F
from django.db import transaction


def increment_counter_atomic(request, name):
    with transaction.atomic():
        # Atomically increment the counter
        Counter.objects.filter(name=name).update(value=F('value') + 1)
        counter = Counter.objects.get(name=name)
    return JsonResponse({"name": name, "value": counter.value})

Testing again with ten concurrent requests, our counter now increases from 1 to 11, which is what we want:

This is a simple and efficient solution, but it is limited to simple operations that can be expressed as an atomic update.

Solution 2: Change Isolation Level to Serializable

A more radical option is to modify the Django settings to use a different isolation level, such as repeatable read or serializable. This can be done for the entire application directly in the Django settings :

from django.db.backends.postgresql.psycopg_any import IsolationLevel

DATABASES = {
    # ...
    "OPTIONS": {
        "isolation_level": IsolationLevel.SERIALIZABLE,
    },
}

The Serializable isolation level prevents concurrent transactions from interfering with each other. It ensures that transactions are executed as if they ran sequentially.

However, serializable transactions may fail with serialization errors if concurrent transactions conflict, requiring retries. Stricter locking can also significantly impact performance.

Alternatively, this can be done for specific raw queries by explicitly setting the isolation level, as shown below:

with connection.cursor() as cursor:
   cursor.execute("BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;")
   cursor.execute("SELECT ... ")
   # ...

Solution 3: Use `select_for_update()` for Complex Queries

Reading and updating an object through multiple steps is a very common use case and is supported by modern relational databases, thanks to the SELECT ... FOR UPDATE statement. With this statement, the rows that are selected are locked, preventing any concurrent update until the current transaction is committed

When we try to use this statement, the rows that we are trying to access may be already locked by another transaction. In that case, we have several options:

wait until the concurrent transaction finishes
don't wait and return an error (NOWAIT)
skip any locked row (SKIP LOCKED)

Django includes a select_for_update function in its Queryset API , with the following signature:

select_for_update(nowait=False, skip_locked=False, of=(), no_key=False)

Note that rows of selected objects specified in select_for_update are locked in addition to rows of the queryset’s model.

Using this function, we can build a new view that will lock the counter instance to prevent concurrent updates:

import time

from django.db import transaction
from django.http import JsonResponse

from .models import Counter

def increment_counter_lock(request, name):
    with transaction.atomic():
        # Lock the row to prevent concurrent access
        counter = Counter.objects.select_for_update().get(name=name)
        time.sleep(5)
        counter.value += 1
        counter.save()
    return JsonResponse({"name": name, "value": counter.value})

Running our test script again, we can see that the counter is properly incremented. However, even if the requests are sent concurrently, they are only executed sequentially due to the lock on the counter table. The screenshot below shows the timestamp when each response is received, with a clear 5-second delay between each response.

5. Conclusion

Lost updates are a common issue when using the default Read Committed isolation level in relational databases. Ignoring this issue can lead to concurrency bugs that often manifest at higher scales or under heavy load.

In a Django application, you can prevent lost updates using the following techniques:

Switch to Serializable Isolation for strict guarantees, but with a performance trade-off.
Use F() expressions for atomic writes when operations are simple.
Leverage select_for_update() to lock rows during complex updates.

Choosing the right approach depends on your application's requirements for consistency and performance.

6. References and Further Reading

Below are resources that provide more context and depth to the topics discussed in this document:

Django QuerySet API Reference: Detailed documentation on QuerySet methods, including select_for_update and F() expressions.
PostgreSQL: Transaction Isolation: Explanation of the different isolation levels supported by PostgreSQL.
MySQL: InnoDB Isolation Levels: Information on MySQL's implementation of isolation levels and their guarantees.
"Designing Data-Intensive Applications" by Martin Kleppmann, Chapter 7: An excellent overview of transaction concepts and their implications for developers.

These resources will help you dive deeper into Django, database isolation levels, and concurrency handling techniques.

Thomas Tartière's blog - django

Understanding Cookies and CSRF with Django

Intro

Table of Contents

1. What Cookies Actually Are

2. How Django Session Authentication Works

3. What CSRF Attacks Are (and Why We Care)

4. How Django’s CSRF Protection Stops This

Step-by-Step Example

Why This Works So Well

5. How Cookie Attributes Keep Things Safe

HttpOnly

What it does

Why we use it

Attack it mitigates — XSS token theft example

Notes

Secure

What it does

Why we use it

Attack it mitigates — network eavesdropping / man-in-the-middle example

Notes

Path

What it does

Why we use it

Attack it mitigates — limited-scope misused cookie example

Notes

SameSite

What it does

Why we use it

Notes

Expires / Max-Age

What it does

Why we use it

Attack it mitigates — long-lived stolen cookie example

Notes

Versioned Static Assets in Django with Docker

Introduction

The Problem with Static Files in Django Deployments

Option 1: Run collectstatic During Deployment

Option 2: Run collectstatic During Docker Build

A Versioned Approach to Static Assets

Overview

Implementation Example with django-storages

Docker build command

Key Considerations

Conclusion

Avoiding Lost Updates in Web Applications

Introduction

1. The Problem: Lost Updates with a Django API Endpoint

Demo app

Simulating Concurrent Requests

2. Understanding Read Committed Isolation Level

What is Read Committed?

What it Doesn't Guarantee

3. Solutions to Avoid Lost Updates

Solution 1: Atomic Write with F() Expressions

Solution 2: Change Isolation Level to Serializable

Solution 3: Use select_for_update() for Complex Queries

5. Conclusion

6. References and Further Reading

Option 1: Run `collectstatic` During Deployment

Option 2: Run `collectstatic` During Docker Build

Implementation Example with `django-storages`

Solution 1: Atomic Write with `F()` Expressions

Solution 3: Use `select_for_update()` for Complex Queries